[Zope-Perl] Threads

Gisle Aas gisle@ActiveState.com
21 Jun 2000 00:16:51 +0200


Gurusamy Sarathy <gsar@activestate.com> writes:

> 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.

I guess I need to try to understand perl threads better.  Until now,
this has been an issue I have been able to ignore.

> >      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)

Can I avoid that the mutex remain blocked, and thus my (only)
interpreter, if the perl code executing goes to sleep or invoke some
other slow system call?

>   * 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.

What is TLS?

>     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...

And when the perl code activated here calls back into python code that
calls back into perl code...  No problem or what?

>         }
>         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.

I don't think we can expect python to tell us when it creates new
threads.  Have to discover this at call time.

And I don't yet want to think about the possibility that perl code might
also create new threads that themselves want to call back into python :-(

--Gisle