develooper Front page | perl.perl5.porters | Postings from May 2003

Re: Last Call For (Least) Favourite Issues For 5.8.1

Thread Previous | Thread Next
Stas Bekman
May 18, 2003 19:21
Re: Last Call For (Least) Favourite Issues For 5.8.1
Message ID:
Jarkko Hietaniemi wrote:
>>In particular I think it's very important to resolve the problem of using 
>>ithreads in applications that spawn their own threads (not via perl), like 
>>threaded mpms in httpd 2.0. Before this problem is solved we can't offer 
>>the DBI threads-based pooling.
> As we heard from Arthur he is not going to work on threads for a while
> at least, and he has a good alibi, too.  So our major ithreads resource
> is unavailable for some time.

A few weeks ago Arthur has said over irc that he has an idea how to resolve 
the problem (described below), I don't know where this issue stands right now.

> Nevertheless, could you elaborate on 'the problem of using ithreads in
> applications that spawn their own threads (not perl)'?  To the first
> approximation, if the application doesn't give an API for accessing
> and controlling those other threads, we are fucked (to use a technical term).
> If, say, a library starts up a POSIX thread using pthread_create(),
> there is very little we can do anything about it (know about it,
> stop it, get results from that thread, see it) unless the library
> cooperates (by giving an API).  Throw in other OS level thread systems
> and models than POSIX, like e.g. Win32 and we are even more fucked.

The short summary of the problem:

threads.xs stores parent ithread's data in TLS on boot, perl_clone()'d 
interpreters running from threads not created by threads.xs can't access that 
data. The ithreads data has to be stored in the perl interpreter itself.

Full details are available from here:

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

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About