NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
an endless discussion thread about what features to include.
-- Jarkko Hietaniemi
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Did I miss something? (Score:1)
I’m still waiting for the point where you show why ithreads aren’t merely a bad emulation of
fork()for Windows. Why would someone who is not personally interested in deploying tofork()-enabled systems ever choose ithreads overfork()? I don’t see any good reason, particularly since a threadedperlis ~20% slower (and somewhat more memory hungry) across the board – no matter whether it’s ever going to run any threaded code or not. And if you exclude Windows from the portability criterion (which is not the point of the exercise, I know), thenfork()meets every single one of your requirements.Reply to This
Re: (Score:1)
If you want to pass non-trivial data around between multiple threads of execution, (i)threads are a far more convenient solution than implementing your own marshalling/serialization code and using fork().
Re: (Score:1)
Apart from Corion's convenience argument, I don't know a good reason why ithreads are much better than fork() for non-portable code. Maybe that managing a bunch of threads seems a bit easier to me than managing a bunch of processes (no zombies).
Maybe I wasn't clear enough on some things: I don't particularly like ithreads. It's just that they're the best solution (known to me) in some cases.