I've learned a bit more about Perl Ithreads. There is a lot that isn't
documented yet so I had to go to the developers.
The idea is that there is a function called "share" that you use to
share a value. Once you do so, the Perl interpreter builds a transparent
proxy that ensures that it is handled in a thread-safe way. Thus you
incur a performance price for only the variables you share. On the other
hand, that price sounds much higher than the price of sharing things
using the global interpreter lock (both in performance and coding
complexity). Therefore it is not a good replacement for the GIL but
perhaps a good alternative for those who need multiprocessor
performance.
According to Arthur Bergman:
"One could say that we do "proxying" internally, but that is totally
transparent to the perl programmer."
sub foo {
my $object = {};
bless($object, "Class");
share($object);
return $object;
}
"
Here's an interesting late-night idea of mine...could shareability be
contagious? If you followed a reference from a shared object to an
"ordinary" object in a different thread, the interpreter could build the
proxy for you. Actually I think that this is how XPCOM proxies work. The
more you work with stuff that came from another thread, the more your
program slows down. But if you copy data when it makes sense, you get
back to indpendent interpreter speeds until you need to share data
again.
--
Take a recipe. Leave a recipe.
Python Cookbook! http://www.ActiveState.com/pythoncookbook
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4