On Wed, 20 Jun 2001, Paul J. Reder wrote: > Jeff Trawick wrote: > > > > Please tell me how I'm confused... > > ... > > We want to get rid of a whole process. > > > > If we write one char to the pod and connect() one time, we tell one > > process, call it process A, to go away but we leave 19 other threads > > in process A stranded in accept(). Processes B and C are unaffected > > so far. > > > > If we write to the pod and connect() again in hopes of waking up one > > of the 19 threads stranded in process A, we likely will tell process B > > or process C to go away since there is no guarantee which thread will > > be awakened by the kernel. > > Since worker_thread is given the child_num of the process, could we not > send the child_num of the killing process on the POD so the kids can > check. If it doesn't match their process number (i.e. if this is a B or C > thread) then they ignore it, or pump it back onto the POD. > > We may need to loop sending the POD message and joining threads until we > have hit all 20 desired threads. > > Any joy here? No. The problem is that you can't ever be sure that you will actually kill the child process. There is nothing saying that a loop sending 20 characters down the pipe will wake up 20 different threads. For the threaded case, you MUST have a mutex around the accept call, but you can still avoid the poll call. Ryan _______________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 -------------------------------------------------------------------------------
