|
Description
|
peter.memishian@East 2000-03-14
In the case where a door server procedure is passing back a descriptor to
a client, it can mark the descriptor with the DOOR_RELEASE attribute if it
wants doorfs to close (release) the descriptor after it has been passed to
the client.
However, in the case where the client has gone away while the door server
procedure was executing, DOOR_RELEASE-marked descriptors passed back via
door_return() are not released; this is consistent with the documentation
(since the descriptor was never *passed* to the client) but not very
useful.
The reason this isn't useful has less to do with DOOR_RELEASE than with
the bizarre semantics of door_return(). In particular, door_return(3DOOR)
states:
If there is not a client associated with the door_return(),
the calling thread discards the results and blocks waiting for
the next door invocation.
As a result of this, there's no way for the server to tell whether the
client went away or not and thus whether it should close(2) the derelict
descriptor itself.
It seems like the easiest way to handle this case would be to extend
door_return() slightly to also release any descriptors marked DOOR_RELEASE;
that is, to augment the semantics of door_return() in this case to be:
If there is not a client associated with the door_return(),
the calling thread discards the results, releases any passed
descriptors with the DOOR_RELEASE attribute, and blocks waiting
for the next door invocation.
|
