A. Bergman wrote
Note that this worked just fine with the old 5.005 threads (which shared everything). I understand that they have ripped the old 5.005 threads out starting with 5.10 but you can still use 5.005 threads with current versions of Perl. We (GreenLight) have been using 5.005 threads in production code for years and it works great (although we did NOT use locks - we count on scheduling).
Are you using 5.005 threads in 5.005 or in 5.6/5.8, since all new features added in 5.6/5.8 did not take threading in consideration, they are not threadsafe.
I understand GreenLight is having trouble with the fact that 5.005 threads are leaving, but if you were ever running more than one thread at the same time, I fail to see how you could have failed to segfault in the extreme amount of cases perl was not threadsafe.
What do you mean "count on scheduling"?
We dispatch one thread at a time. That is, we use threading as a powerful programming paradigm (it would take too long to explain what we do here) and not as a way of taking advantage of a multiprocessing environment. "Count on scheduling" means that we do not suspend/dispatch tasks when they are in an "awkward" state. We even #defines all of the Perl locks into no-ops for performance since we do not need any of the locks.
5.005 threads were a true threading system that was well integrated into Perl and allowed full use of Perl data structures. Eduardo's example shows one of the key advantages: with 5.005 threads you can use any variable normally without restriction. That includes deferencing and updating. All threads work from the same copy. The Perl garbage collector automatically released space when the reference count went to zero. The power of this is somewhat subtle yet easy to use and truly remarkable (I know of no other language that can do this). The ithread copy/share scheme is not nearly as powerful and makes some things virtually impossible (as Eduardo has discovered). Here is a snippet of sample code - if someone can tell me how to do this with ithreads I'll be greatful:
sub newThreadForFoo { my foo $ref = shift; Thread->new(sub {wait(3); if ($ref->{Ready} {update($ref)}); }
same code should work, if whatever $ref is point at is shared.
But that is the point: there is no way in ithreads to make everything shared so you cannot be sure that dereferencing $ref will work. Things like code closures cannot be shared and I don't think that objects can be shared (i.e., my $foo = []). It is probably possible to extend the shared attribute to cover these cases but then we'd need to change every public package (plus tons of code written by our customers) to use this. What we are looking at doing is providing a "share everything, copy nothing" option with ithreads. But that doesn't seem to be as easy to implement as it is to describe. And, of course, internal stuff would be unprotected with this option if anyone used it in a true MP environment.
I'm not trying to say that ithreads are not a Good and Useful thing - they are just a totally different programming paradigm than 5.005 threads. But ithreads is nowhere near a replacement for 5.005 threads (at least with the current implementation).
So what is lacking in the current implementation?
The ability to share everything, like 5005 threads. Performance (copying the whole environment is rediculously expensive).
At GreenLight are trying to decide what to do in the future - retrofit the old 5.005 code back into 5.10 and beyond or make significant modifications to ithreads so that the 5.005 paradigm can be supported (it isn't clear if the latter is possible).
I would be happy to discuss how ithreads can be extended the need of 5.005 users, I think retrofitting the old 5.005 code is possible, but if you want to use the new features, it would require a lot of work. Way more work than it took to get ithreads working.
I've yet to see any new features of ithreads that are superior to 5.005 threads (well, except for the big one that ithreads actually work in a true MP environment). On the flip side, there are many restrictions that limit ithreads (just scan for things in util.c that start with a comment "Only the parent interpretor can.....".).
Like I said before, I'm not trying to say that ithreads are not useful. Its just that the set of things that ithreads can be used for and the set of things that 5.005 threads can be used for are considerably disjoint. My objection is not to ithreads per se, it is to the philosphy that "we've got ithreads now so lets yank 5.005 threads out of Perl". They are very, very different things
- Jim
