ActiveState, threaded fork and re-entrancy

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.

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.

Comment on ActiveState, threaded fork and re-entrancy Download Code

Replies are listed 'Best First'.
(tye)Re: ActiveState, threaded fork and re-entrancy by tye (Sage) on Aug 02, 2002 at 16:19 UTC
perrin is correct. But that hasn't stopped the use of (the emulated) fork in Win32 Perl (it is not specific to ActiveState releases) from making scripts behave strangely. In my experience, even trivial scripts that use fork don't behave properly. I'd love to hear that Perl v5.8 has drastically improved this situation. But I won't believe reports from the porters as they had previously reported that it mostly worked. (: - tye (but my friends call me "Tye")	[reply]
Re: ActiveState, threaded fork and re-entrancy by perrin (Chancellor) on Aug 02, 2002 at 15:57 UTC
Don't worry, the approach used for fork emulation is separate perl interpreters in each thread with nothing shared between them. There are details about copy-on-write, etc. but they are not important for this kind of consideration.	[reply]
Re: ActiveState, threaded fork and re-entrancy by Elian (Parson) on Aug 02, 2002 at 17:01 UTC
Almost everything's separate, but there are still issues with regular expressions (which aren't fixed until 5.8.0) and potentially with C extensions which, regardless of what you see at the perl level, see things as threaded rather than forking. Not all XS plays nice with threads. Regexes are your big issue though. The way the match variables are implemented will kill you dead at unpredictable times.	[reply]