I don't mean to be incendiary. I am interested in Perl's ithreads, and wish that they were a viable option. I've played around with threads in 5.6.x, was quite excited at the prospect of them becoming better with 5.8.x and played some more. I've read (as a lurker on p5p) the messages from people like Arther, Liz and Stas working to make threads useful.
However, I feel that Liz's post is still very appropriate, and that's why I bring it up. Perl's ithreads have had many fixes applied to them, but the problems pointed out in that post (all data structures are copied, shared variables take up extra memory) are still true.codon's update says that he needs to cache a large amount of data in memory. Having long lived threads limits cpu hit incurred by copying that cache. But the lack of either COW or truly shared memory limits the number of threads that can be running simultaneously to (ramsize - os overhead) / (cache + thread overhead). This is a big hit for memory intensive applications.
Basing your judgment on Liz's post, is like saying "Perl can't do structured data", based on the docs for Perl4--it is wildly out of date.That's quite an exaggeration. The difference in Perl data structures between 4 and 5 is dimensional. The difference in Perl's ithreads between 5.8.1 and 5.8.7 fixes a ton of memory leaks and crashes, but they constitute no paradigm shift.
By recent talk on p5p, I'd guess that Liz's future speculations remain as good a prediction as ever (don't expect for better threads (regarding memory usage) until ponie/parrot/p6). Things will continue to improve for 5.10.x, but I don't see it being likely that we'll get COW or real shared data.
-Colin.
WHITEPAGES.COM | INC
In reply to Re^4: Reliable asynchronous processing
by cmeyer
in thread Reliable asynchronous processing
by Codon
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |