[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