in reply to Re: Re: Perl threads - telling them urgent stuff
in thread Perl threads - telling them urgent stuff

POE looks interesting, and there's a Win32 version of it :) I've only scanned the docs but this might be a good way to go. One thing I've noticed about perl ithreads is that they seem to take so *long* to initialise, at least on Win32, that threading little asynchronous functions whenever you need them can actually make the code run significantly slower :/ This is undoubtedly because perl copies the whole heap to the new thread, and I guess the performance problems with this is exactly why other threading APIs dont do it.
  • Comment on Re: Re: Re: Perl threads - telling them urgent stuff

Replies are listed 'Best First'.
Re: Re: Re: Re: Perl threads - telling them urgent stuff
by BrowserUk (Patriarch) on Oct 20, 2003 at 21:39 UTC
    ...threading little asynchronous functions whenever you need them can actually make the code run significantly slower...

    Indeed. Whilst spawning a thread at the OS level is relatively fast, the non-reentrant nature of the perl runtime requires that the whole of the interpreter be replicated to avoid conflicts with global data. Whilst an effective solution to some of the problems seen with the previous pthreads implementation, it results an a substantial startup penalty. It also gives rise to some pretty fundemental caveats.

    Using ithreads effectively, requires a pretty good understanding of the caveats, and designing your use of threads around them. liz covers many of these in Things you need to know before programming Perl ithreads. It's well worth a read if you intend to pursue using ithreads.

    Some very clever people have done a huge amount of work to get ithreads to where they are now, but the fundemental constraint of the interpreters non-reentracy persists and is unlikely to change before Ponie hits the repositories.

    As threads are a core design feature of Win32, there are many facilties of the the OS implementation that I would love to have access to from perl. The problems in gaining that access are two-fold.

    1. It would require access some of the data structures and state that the perl internals use to manage threads, which means writing patches in C or XS to expose them, which is a distinctly non-trivial task.
    2. It would entail either
      • Writing a Win32-only extension to the current ithreads api.
      • Trying to design the extensions such that they formed a generic extension that could be easily implemented on other platforms.

    The former would likely gain little support from the core maintainers as it moves away from the cross-platform ideals of perl.

    The latter is very difficult to do. The platform specific nature of the native Win32 threads API's combined with a host of general perl features (read: unix system features) that aren't supported or only trivially emulated on Win32, would make the task of designing a true cross-platform solution extremely hard.

    I can see some ways that the current support for threads could be improved (along with the current emulations of some of the unix system concepts), but my attempts at futzing with the perl sources have been a disaster and extremely frustrating. My hat is off to those that do this regularly, they should be given medals.

    All in all, I'm hoping that the ground up design of Parrot and Ponie will make the situation better before too long... and that the mouth-watering promise of P6 won't be too far away.


    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "Think for yourself!" - Abigail
    Hooray!