Re: Problem with message system

[joerg.wittenberger@inf.tu-dresden.de (Joerg Wittenberger) writes:]

>But I have a thread acting as a server for threads of the same process.
>If I kill the process I see no way to ensure that all pending requests
>get rolled back. Thus my process works fine except I try to kill it.
>Then it'll hang forever.

I don't think you've found the real problem yet. The networking daemon uses
the same technique, and work OK. I bet if you do a "ps" after you kill the
process, you'll see the process still there with "nthread" reduced by one.
Kill it again, and I bet "nthread" goes down by another. When you get all
the threads, I bet you'll see the process exit.

>A second question: While I see (at the moment) no solution for the
>above I can't exit my process in a really clean way anyway. I tried
>to notify() the client threads (which correctly generates the M_ABORT)
>then wait until they are gone and then notify() the server thread.
>Unfortunatly I'm either to stupid to call wait_pid() correct or it
>doesn't work right. Anyway if I call wait_pid() it immediately
>returns. Thus I'm going to kill the server thread before all the
>M_ABORT's are done:-( Currently I just sleep() for 2 seconds after the
>wait_pid() to give them a chance, but that's certainly not the
>solution I'm looking for.

There certainly could be a bug in the waitpid() code--there used to be, in
any case. If you can find a line:

        *ip = encode(ep);

Instead of the line:

        *ip = encode(&e);

Then patch it to the latter. Otherwise I guess it's a new bug. Another way
to handle this is to use the waits() system call directly (instead of
through POSIX emulation). This'll at least tell you if it's the
wait/waitpid emulation, or a problem with the underlying process death
handling.

                                                                Andy
Received on Sun Jan 22 07:48:05 1995