Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Re^4: Isolating dynamically loaded modules with Thread::Isolate.

by BrowserUk (Patriarch)
on Jan 31, 2005 at 03:18 UTC ( [id://426492]=note: print w/replies, xml ) Need Help??


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

This node falls below the community's threshold of quality. You may see it by logging in.

Replies are listed 'Best First'.
Re^5: Isolating dynamically loaded modules with Thread::Isolate.
by tilly (Archbishop) on Jan 31, 2005 at 09:12 UTC
    Weakness in the eye of the beholder.

    Most of the complications in Perl's threading model come from trying to figure out how to add threading and avoid having the interpreter randomly deadlock or corrupt from race conditions. I take problems like that seriously.

      Weakness in the eye of the beholder.

      Agreed. And if the beholder stands a mile away atop a pedastal, they get a particularly bad view.

      Your throwaway, uninformed, and fatuous statement is equivalent to saying that "Using Unicode is bad, because it leaves you open to getting all them funny foreign characters".

      FYI: Ithreads do not "randomly deadlock or corrupt from race conditions".

      Indeed, you may start as many threads as you like and leave them running until doomsday, and they will never do so, unless you, the programmer, create the a situation in which that can occur. And it is just as possible to create either of those errors when programming communications between processes.

      So the programmer can create these problems whenever they write bad IPC code. Your conjecture that this is a "threads problem" is just FUD.

      However, if you need to communicate between asyncronous tasks, then iThreads provide mechanisms--coded by experts to avoid those problems--that mean that the programmer can avoid having to learn how to perform the communications themselves.

      Ergo, if you need to multitask, and you need those tasks to talk to each other, it is easier, safer and quicker to do that with threads. It isn't even complicated--done correctly.


      Examine what is said, not who speaks.
      Silence betokens consent.
      Love the truth but pardon error.
        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.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://426492]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others romping around the Monastery: (9)
As of 2024-03-28 23:56 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found