Stories
Slash Boxes
Comments
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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 to fork()-enabled systems ever choose ithreads over fork()? I don’t see any good reason, particularly since a threaded perl is ~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), then fork() meets every single one of your requirements.

    • 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().

    • 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.