Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

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

by BrowserUk (Pope)
on Jan 31, 2005 at 16:20 UTC ( #426640=note: print w/replies, xml ) Need Help??


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

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.
  • Comment on Re^6: Isolating dynamically loaded modules with Thread::Isolate.

Replies are listed 'Best First'.
Re^7: Isolating dynamically loaded modules with Thread::Isolate.
by tilly (Archbishop) on Jan 31, 2005 at 23:56 UTC
    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.

      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.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (3)
As of 2021-04-12 23:01 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?