Re: can't kill fd server

On Thu, May 21, 1998 at 10:28:27AM -0700, Andy Valencia wrote:
> [David Jeske <jeske@home.chat.net> writes:]
>
> >I've seen this problem in the past with "unkillable servers" I'm not sure
> >if it was fd or not. However, I just recently noticed the same thing once
> >with fd. Not only can you not kill fd, but you can quickly create a "chain
> >of no-death" as trying to kill the "kill fd" process will also hang.
>
> Yes, I've looked into it, and it poses an interesting issue. The problem
> occurs with multi-threaded servers where threads talk to each other with
> kernel IPC. What happens is that a client thread is blocked waiting for an
> answer from the server, and the server thread dies without unblocking this
> client. If the server were in a different process, the exit of the last

Do you mean "if the server were in another process and _it_ was being
closed down" or "if the server were in another process and the client was
being closed down"?

Or to rephrase, does the problem occur because the server side of the
IPC deadlocks, or because the client side of the IPC deadlocks?

> thread causes all ports to be torn down, which would unblock the thread.
> However, in this case, the waiting thread is in the same process, so the
> server port is not scrubbed, and a deadlock results.

> I'm looking at a change so that server ports are related to the thread which
> created them. Thus, it only requires the death of the server thread to
> cause a port to be scrubbed, which breaks this deadlock. This should work
> for most server which come to mind, but I want to look at some "pool of
> thread" servers which exist. The KA9Q port comes to mind, for instance.

I don't understand why there is a relationship between killing a thread
and unblocking it. Why does it need to be unblocked at all?

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske_at_chat.net