http://qs321.pair.com?node_id=426767


in reply to Re^6: Isolating dynamically loaded modules with Thread::Isolate.
in thread Isolating dynamically loaded modules with Thread::Isolate.

Obviously the fundamental problem has to do with race conditions in IPC communications, which is not just limited to threads. However multi-threaded processes tend to have so much more than other cases in the way of sharing that they are more prone to those problems than other programs.

As for whether iThreads protects you, I have to admit that its very heavyweight approach leads to far less sharing than in most threading models, which does offer some protection. OTOH I'm far from sure that there are no race conditions left in the regular expression engine. Furthermore Perl's iThreads cannot protect you from the possibility that there are race conditions in various third-party C libraries that you might have loaded. Now you can claim that choosing to use regular expressions or third-party C libraries is a case of the programmer creating the problem. And to some extent that is true. But it doesn't much help the programmer who is trying to fit together black boxes and may not understand in detail what is in those boxes.

As for whether you'd be better off with a different approach, well on any *nix you can just use multiple processes, known methods of IPC, and you get similar facilities to Perl's iThread model with better performance and better protection. In fact Elizabeth Mattijsen managed to implement iThreads using fork, and from what I understand the result is the pretty much the same except that it is faster, less bug-prone, and uses less memory.

Replies are listed 'Best First'.
Re^8: Isolating dynamically loaded modules with Thread::Isolate.
by BrowserUk (Patriarch) on Feb 01, 2005 at 00:09 UTC
    In fact Elizabeth Mattijsen managed to implement iThreads using fork, and from what I understand the result is the pretty much the same except that it is faster, less bug-prone, and uses less memory.

    That is so wrong.

    Forks not only duplicate everything as iThreads do, they do it by using Storable and passing everything through sockets between the processes and all locking and synchronisation is duplicated and much harder. Whilst they showed some early promise and were somewhat more reliable than ithreads in builds 5.8.0/1/2, they achieved that by being even slower, clumsier and heavier than that which they attempted to replace.

    Your information is secondhand and totally out of date.

    The rest is more red herrings.


    Examine what is said, not who speaks.
    Silence betokens consent.
    Love the truth but pardon error.
      You claim that forks duplicate everything? I think not. At least not on any OS which implements copy on write memory, which would be any semi-current *nix. And in many applications it is OK if communication overhead is slightly more in order to benefit from the saved memory and increased protection.

      As for the rest, I haven't tracked to see if people's experience with Perl's threading in the last half year is as bad as it had been before that. It probably has improved, though not to the point where I'd be willing to put it into production. But my general comments about threading remain true, and my specific comments about Perl's thread model in specific are, to the best of my knowledge, accurate. If you have specific examples to change my mind, that would be one thing. But you don't appear to, instead you're just telling me that what I've said is red herrings and wrong, without providing me with any specifics.

      Since I feel no need to convince you of anything, and I don't feel that this conversation is going anywhere I'm exiting the conversation here.

        instead you're just telling me <<...X...>> without providing me with any specifics.

        That is exactly the problem I have with your posts. It is impossible for me to either counter or agree with non-specific FUD.


        Examine what is said, not who speaks.
        Silence betokens consent.
        Love the truth but pardon error.