We are using ActiveState Perl 5.6 in our shop.

I have read in several places, for instance in this thread, that the ActiveState Perl 'simulates' forking by using threads. I have a lot of personal experience in writing multi-threaded code in classical 'C'. (Classical, as opposed to C++.) That was under OS/2 (R.I.P.) so it was a while ago and I may not remember everything absolutely correct but I think the following is true.

• In a truly fork'ed application, each pid becomes a separate process and is in fact a copy of the parent application. To share information (events or data) between the pids, some kind of IPC must be used.

• In a threaded application this is not the fact, but global resources are shared between all threads and must be protected, normally using semaphores. Events and non-global data must be shared using pipes, queues or other IPC mechanisms. When compiling a truly threaded application in C, the compiler 'promises' that stack variables in each C function will be unique to the function instance executed. If two or more threads execute the same C function simultaneously they will share the code, but not the stack variables.

I then started to think. And this is when it got hairy...

• Can a sub my_complicated_calculation(){} be used by more than one simulated forked process, actually implemented as threads in AS Perl?

• Isn't there a risk that the 'my' variables in that common sub will be overwritten if my_complicated_calculation() is concurrently called from two or more threads?

• What about global variables?

• Is this all taken care of by the Perl interpreter, or do we have an issue here migrating a forking Perl application from UNIX to Win-32?

---

Everything went worng, just as foreseen.