in reply to Parrot, threads & fears for the future.

Thank you for posting this.

I have a question about the failed ithreads experiment though. I thought the biggest problems with ithreads were that:

Those all seem like implementation details, where the most important point of an ithreads model is default shared nothing -- which has tremendous advantages with regard to locking semantics.

What am I missing?

Update: audreyt and Liz are right; I read the threads source code, rather than grepping through the *.c files for Pthreads calls.

  • Comment on Re: Parrot, threads & fears for the future.

Replies are listed 'Best First'.
Re^2: Parrot, threads & fears for the future.
by audreyt (Hermit) on Oct 23, 2006 at 16:09 UTC
    Hmm. Having all builtin Array/Hash/Scalar structures be implicitly transactional and locklessly shared, then allow explicit non-shared cloned state and channels on top of that, seems to me to be easier to scale and reason about, than the other way around.

    Also, native OS threads are still in a single process in Unix, and Perl 5 does use 1:1 mapping from Perl threads to native OS threads on Unix, where pthreads is available (see thread.h). Which is also expensive, as 1:1 mapping is only necessary if you do blocking system calls. So I'm not sure your first point (that the entire program only use one pthread) holds...

[reply]
Re^2: Parrot, threads & fears for the future.
by liz (Monsignor) on Oct 23, 2006 at 16:57 UTC
    They don't use native threads; the entire program is still a single process still uses only one native thread. (I don't understand the Windows threading model, but I'm pretty sure what I said is true on Unix-like platforms.)
    This is not true generally. On unixen, the local thread implementation is used for providing threads, but each thread has its own interpreter and its own copy of the data structures.

    There's still way too much global state in Perl 5.
    I don't think this is necessarily true in the core Perl modules. It's third party XS based modules with their own ways of accesing perl's internal structures, that cause problems in many cases.

    Cloning an interpreter and the global state is hideously expensive.
    Indeed. All stashes and their contents, as well as all live lexical values, are copied. They only thing I understand that is not copied, are optrees. Shared variables are even worse, because they not only exist in a thread and the threads started from that thread, they also exist in the "shared variables" thread (which is a hidden thread used as a safe haven for shared variables).

    Liz

[reply]

In Section Meditations