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.

TIA

Well, as a first approximation:"fork" works, "threads" don't. {grin}

-- Randal L. Schwartz, Perl hacker

This is a complex subject, but you got me in a good mood. :-)

A full response may be found at Threads vs Forking (Java vs Perl).

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?