in reply to Re^15: threading a perl script
in thread threading a perl script

At least for Python, your assertion is partially incorrect. The GlobalInterpreterLock "prevents multiple native threads from executing Python bytecodes at once", but (other than that), Python threads are native OS threads. You don't get as much benefit from these threads while running inside of Python, but at least C extensions (and it seems also blocking system calls) can release the GIL to other code.

Replies are listed 'Best First'.
Re^17: threading a perl script
by BrowserUk (Patriarch) on Apr 26, 2011 at 15:09 UTC

    You're right. It is much worse than that.

    It spawns native threads, but then uses them like grean threads. Except that the internal 'scheduler' is so poor that it has to run in perceptual debug mode. Thus totally preventing any form of usable concurrency.

    Its like saying: Of course every one can have the privilege of owning their own car, sit in their own private space, listening to their own choice of music. But to go anywhere, you have to wait for the car-train to arrive, join the queue and follow it wherever it goes until (if you are lucky) it goes past your exact destination. At which point you can leave.

    It has all the costs with none of the benefits.

    I guess it does serve to highlight how difficult it is to implement kernel threading in a dynamic language; and just how f***ing amazing iThreads really are. Imperfect for sure. But still amazing, given that they were retro-fitted without breaking backward compatibility and are so usable and scalable.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.