Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

RE: RE (tilly) 2: When is a while not a while?

by jreades (Friar)
on Aug 25, 2000 at 16:47 UTC ( #29610=note: print w/replies, xml ) Need Help??

in reply to RE (tilly) 2: When is a while not a while?
in thread When is a while not a while?

What are the tradeoffs between fork() and threads?

As I said, I've only used threads in Java (which AFAIK has no forking) and they are one of the fundamental classes... Anyway, tradeoffs: discuss.


  • Comment on RE: RE (tilly) 2: When is a while not a while?

Replies are listed 'Best First'.
RE: RE: RE (tilly) 2: When is a while not a while?
by merlyn (Sage) on Aug 25, 2000 at 17:39 UTC
Threads vs forking
by tilly (Archbishop) on Aug 25, 2000 at 17:49 UTC

      Well, you supplied a great explanation (particularly in combination with the geeksalad article) -- I now know just enough to be dangerous. :^P

      Let me see if I understood what was written and can apply it to the problem at hand...

      We need one application/process/thread ('a') to instantiate/launch/spawn another ('b') that will perform function 'x' while 'a' waits for keyboard input...

      Under Unix/Perl, this would be an exec situation as we don't need 'a' to clone itself, but we *do* need it to launch 'b' as a distinct process.

      Now there are two possibilities, depending on whether or not 'a' and 'b' need to communicate after the exec().

      If they do not -- i.e. that 'b' will run until it has done 'x' and then exit.

      But if 'a' and 'b' still need a way to communicate, then we need to avoid trampling all over the shared information (a 'race condition'). One way of avoiding this is supplied by tilly as SimpleLock, and I think that this LockFile-Simple might also allow the processes to pass information back and forth.

      Am I on the right track?

        In Unix when you fork you usually wind up communicating between the processes in a pipe. With threads the two can communicate directly through an internal buffer (they share the same memory). With Unix you don't have to worry about how you use data, but there is more overhead. With threads you do have to be careful because the threads can trample over each other, but you can get better performance.

        Where locking is necessary is when two things (threads, processes, machines in a cluster, whatever) need to synchronize access to the same resource. Think here of Highlander - allow only one invocation at a time of an expensive CGI script, or also think of some CGI script that updates some user file. If your user submits twice you now have 2 processes, one of which might be reading while the other is deleting...

        That is a race condition. If the first cleanly read, rewrote, and exited, you would be fine. The second likewise. If they collide...

        It just happens to be really easy for two threads to collide. And much less common for programs to do it.

Log In?

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

How do I use this?Last hourOther CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (6)
As of 2023-12-03 00:53 GMT
Find Nodes?
    Voting Booth?
    What's your preferred 'use VERSION' for new CPAN modules in 2023?

    Results (20 votes). Check out past polls.