Front page | perl.perl5.porters |
Postings from May 2003
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: http://archive.develooper.com/perl-ithreads@perl.org/msg00649.html __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.comThread Previous | Thread Next