...and you want both branches to start out with the same environment and state...

Of course fork does that, because that's what fork does. Not all, if fact a very large number of multi-tasking problems don't require those semantics...but with fork, you get them whether you like it or not.

To back that statement up, the whole "fork & exec" idiom is my proof. You replicate the environment--and then discard all but a minor part of it.

Many fork and exec programs have to leap through hoops to discard that inherited environment. Just look at the double "fork and exec" shanigans that is required to create a daemon?

But leaving that aside.

You can just do that with processes when you have fork(); you need threads when you don't.

You are still viewing this entirely from the "You only need threads because you haven't got fork" view.

Turn that around and you get the perspective of "We don't need fork because we have threads!".

We can argue about which is the better--most flexible, efficient, resource-freindly, programmer friendly etc. etc.--until we are blue in the face, but we were not there when Gordon Letwin et al made their choice.

At the point in history when that decision was made, replicating processes, even under unix, meant replicating the entire process, code, data, sheduler slots--everything--whereas threads allowed all the code and either some, none or all the data, to be shared.

The advent of COW clawed back a lot of ground--in some cases, it surpasses it. Perl is one of those cases. The significant thing about Perl in this regard is the way data becomes code, and the segregation between those two becomes blurred, because what is code in the Perl sense, is just data in the terms of the underlying C code.

But the main point is that threads are not a lesser substitute for fork--they are an alternative approach to solving similar problems. For some applications the fork approach lends itself directly, for others threads are a better fit. Neither is superior or inferior, they are just different. Each has their pros and cons.

Where Perl and threads fall down, is the attempt to use one as a direct substitute--an emulation--of the other, in an attempt to achieve cross-platform portability. A laudible aim and a heroic effort, but fork isn't the only thing that is done differently on Win32--vis. signals-v-events--and the emulation of signals never quite made it far enough to make the fork emulation compatible, with the fork method of operation.

And in the process of creating iThreads, an, at best, rather limited API was chosen as the model, which means on Win32, it discards about 70% of the native threads functionality and effectively emasculates them. So, here I sit with a barely usable fork emulation *and* severely restricted access to the very usable, very powerful native alternative.

Whereas you sit there, with a fully functional, efficient fork, and threads that, whilst written to a API native to your platform, you'll probably never use because you don't need them.

Though I think if threads did not try to emulate fork, and operated in a more programmer-driven and controllable fashion, then they would be lighter, less memory hungry, more convenient to use and would truely avail the Perl programmer of the benefits of threading--for those applications where they are desirable.

And were that the case, you might be more inclined to consider the possibility of using them.