Hi, I was going to roll 2.0.36, but I want to wait for this last worker change. Unfortunately I don't have the time to pursue the issue now, so if someone does, please feel free to take care of this annoying beast.
Sander > From: Sander Striker [mailto:[EMAIL PROTECTED]] > Sent: 01 May 2002 15:11 >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Trawick >> Sent: 01 May 2002 14:53 [...] >> (My apologies for not keeping up with the discussions over the past >> days.) >> >> I don't see (yet) which segfault this would fix. Maybe I was hoping >> for a fix to the wrong problem... >> >> If this was to be combined with a change to do a thread-join on the >> workers even for graceless termination, then I can see how the >> segfault caused by cleaning up a pool that the worker threads depend >> on would be avoided. (But of course a thread-join on a worker could >> hang for a while, depending on what a 3rd-party module is doing.) >> >> This change alone doesn't do much for the race between the main thread >> cleaning up pchild and the worker threads getting dispatched and >> realizing that they can exit and finally finishing their use of data >> in subpools of pchild and doing the pthread_exit(). > > Grmpf. Ofcourse, you are correct. We need the thread_join as a patch > job. After 2.0.36 I am afraid we have to implement apr_thread_cancel... > > Sander >
