Biker has asked for the wisdom of the Perl Monks concerning the following question:
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.
- 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.
Back to
Seekers of Perl Wisdom