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.

In defense of Perl ithreads 14 Comments More | Login | Reply /

 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 portabilit

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

  • ithreads have two problems:

    1. When you spawn a thread, it copies the whole environment from the parent thread, variables and code. This results in poor performance when a lot of libraries are loaded.

    2. You can't pass a file descriptor from one thread to the other. So you can't create a network server that spawns a thread for each client.

    This makes perl one of the only scripting language you can't use to build a multi-threaded network server, without using fancy stuff like Coro, AnyEvent or POE. Those are gr

    • C:\Projekte\App-CPANr>perl -Mthreads -e "open my $fh, '<', '/boot.ini'; for (async { print for <$fh>}, async{sleep 10}) { $_->join; }"

      [boot loader]
      timeout=30
      default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
      [opera ting systems]
      multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional"
      /fastdetect /NoExecute=OptIn

      • Works great for that. How about starting ten threads, then passing them a filehandle to work on? That's what I was talking about.

        Beside, if you have a lot of stuff loaded (like POE), instead of this trivial exemple, each thread spawn is rather costly.

    • 1. When you spawn a thread, it copies the whole environment from the parent thread, variables and code. This results in poor performance when a lot of libraries are loaded.

      The worst part of this is not just the poor performance but its unpredictability and that the effect is not local but global.

      For instance, to implement a CPAN module doing something specific (as downloading a bunch of files from the Internet in parallel) that you want to be usable from any script, if the module were launching, say, 10

  • You could also consider writing a backend server that your frontend talks to with TCP/IP. I did this with IO::All so that I could have a perlcritic backend that doesn't slow down my client so much.
    --
    --fREW
    http://blog.afoolishmanifesto.com

  • Yes, currently you will have to explicitly cede control to the other coroutines regularly. However, Yuval is currently trying to get his patch [github.com] implementing preemptive coros merged into Coro. Those allow control to be automatically passed to other Coros using different strategies like opcode counting and fixed timeslices. That'd at least solve one of the problems you're describing.

    • That would totally make me reconsider things. Thanks for pointing this out!

    • Of course, by making coroutines actually execute in parallel, you give up the one thing that Coro provides over threads - you invite back in the daemons of locking and deadlocks.

      • Luckily, preemptive coros don't do that. Everything still runs in one process, one coro at a time. Just passing control from one coro to another can happen implicitly, so blocking code that isn't under your control is not a problem anymore.

    • Excuse my gross ignorance, but would this remove the one-core limit?

      Could we then use even half of my four core machine?

      • This would totally not remove the one-core limit. But it would fix essentially all other problems. For multi-core usage, one would have to resort to an extra process.

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.