Re: can't kill fd server

[newsham@lava.net (Tim Newsham) writes:]

>Hmm.. would it still be possible to hand off ports between threads
>after this change was made?

That's precisely the issue. No, it wouldn't, and yes, I think it would
cause trouble with current applications.

As to David's questions:

>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"?

Server in another process, and server closing down (being killed, i.e., an
asynchronous event to server execution).

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

It's a process which is a server, but also has another thread within the
process which is a client of this same server.

>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?

Because a thread in the blocked state represents a number of data structures
which must be moved through further state transitions. For instance, it has
taken the portref, and must come back of it for any other thread to be able
to use that connection. There's also the portref's state, which also goes
back to the mapping of client buffers into the server, and how that
reference is cleaned up.

Also, for the last thread in a process, it is within this thread context
that a number of potentially slow actions are taken--for instance, closing
all open connections.

This all comes down to synchronous IPC. Synchronous IPC means synchronous
with respect to, basically, a thread. If the thread suddenly becomes
asynchronous, most of the design optimizations you gain from synchronous IPC
go away. At least as I envision the fallout of changing VSTa to, for
instance, permit the thread to be silently axed.

                                                        Andy
Received on Thu May 21 08:23:49 1998