Front page | perl.perl5.porters |
Postings from May 2003
> 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. 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. -- Jarkko Hietaniemi <jhi@iki.fi> http://www.iki.fi/jhi/ "There is this special biologist word we use for 'stable'. It is 'dead'." -- Jack CohenThread Previous | Thread Next