perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject [mp2] Our API is not perl thread-safe
Date Tue, 22 Mar 2005 22:23:58 GMT
As I've suspected our API is not perl thread-safe (note that perl's 
thread-safe definition and the general thread-safe concept have little to 
do with each other). I've started writing some tests and it's segfaults 
all over.

It all comes to the same old problem of perl cloning the objects when a 
new perl thread is spawned either from the perl code or in the case of 
threaded mpm, when a new interpreter is started (C's perl_clone() is 
called). When the object is cloned perl doesn't know what we have hidden 
in the IV slot which is a pointer to a C struct. The Example::CLONE [1] 
manpage explains how to deal with this issue. Unfortunately our case is 
much more complicated and there are many questions.


[now take your time to read the Example::CLONE manpage in [1] which 
explains all the issues and shows possible solutions]
[only when you are done, please continue]

I believe some of the mp2 APIs are do-able, others are not quite. So I'd 
like to discuss here some of them.

First of all we have to separate the objects in two groups: those created 
by users (1) and those created by Apache/mp2 (2).

(1) things which are completely under user control look easy, for example 
if you create an APR::Table object, we can clone it by copying the table 
in the spawned thread. The question is what pool should we use for that 
purpose? We can't use the pool from the parent thread. Since the parent 
thread may be killed before the child one (for detached threads). and if 
it's APR::Pool object itself that needs to be cloned, which pool do we use 
to clone it? How do we avoid leaks?

Ideas? I'm not sure it's doable at all.

(2) Things are even harder with objects created by Apache/mp2. I mean how 
in the world are we going to clone things like $r or $c? there are all 
kind of things attached to those objects, including sockets, etc. and now 
we suddenly need to free those objects too.

Here I'm even more lost.

I'm pretty sure that the various random segfaults and scalar leak reports 
we get from the ithreads tests in our test suite come from this issue.

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message