[Zope-Perl] Threads

[Gurusamy Sarathy]

On 20 Jun 2000 15:42:10 +0200, Gisle Aas wrote:
>   1. Concurrency. Execution in the Perl code will be at least as
>      concurrent as execution in Python code.
>
>The other bad thing is that there was a need for a lot of calls to the
>locking macros which makes the code longer and much harder to verify
>the correctness of.
>
>Possible improvements:
>
>    - assume perl is thread safe (the perl-5.005 thread model) and

But the 5.005 thread model *isn't* concurrency safe for a single
interpreter (you can't run the same interpreter in multiple threads
at the same time).  Neither is the 5.6 model, if you're just talking
about running a single interpreter.  Basically, perl doesn't manage
access to interpreter state with locks--the entity that creates
interpreters is expected to do that, irrespective of whether you're
using the 5.005 thread model or the 5.6 thread model.

>      eliminate the perl lock.  One problem here is that the perl
>      lock was also protecting the global where we stored the
>      current "PyThreadState *".  We would then need to figure
>      out a way to store it somewhere else on a per thread basis.
>      Other problem is that the 5.005 thread model is depreciated
>      and does not really always work.
>
>    - allocate separate perl interpreters for each thread.  This
>      is the perl-5.6.0 model.  This sounds complex to me and I 
>      am not sure the semantics will be correct either.  If I
>      understand things correctly, each interpreter will then
>      have their own module/name space.  Not really compatible
>      with the python threading model.

If you want to run the same interpreter in multiple threads with the
5.6 thread model, you can.  All you have to do is:

  * ensure that more than one thread is not executing the interpreter
    at the same time (use a mutex for exclusion)
  * set the perl TLS slot of the executing thread to the interpreter when
    the thread first "calls in".  You may want to save the existing TLS
    and restore it when the interpreter is no longer associated with
    that thread.  The general structure is:

        PerlInterpreter *old_perl = PERL_GET_CONTEXT;
        PERL_SET_CONTEXT(new_perl);
	{
	    PerlInterpreter *my_perl = new_perl;
	    ...call_sv()/eval_sv() etc...
        }
        PERL_SET_CONTEXT(old_perl);

If the entity that creates new threads tells you when it does so,
you may be able to do the PERL_SET_CONTEXT() at thread creation
time, rather than doing it everytime an arbitrary thread calls
into the interpreter.


Sarathy
gsar@ActiveState.com