Re: Rewriting hurdselect.c: How to detect that a file descriptor has disappeared?

[Roland McGrath]

> The construct used in hurdselect is the mach_msg() function:
> 
> __mach_msg (&msg.head, MACH_RCV_MSG | options, 0, sizeof msg, portset,
> to, MACH_PORT_NULL)
> 
> This function call only has parameters set for reading. Can a
> subsequent call using MACH_SEND_MSG parameters and messages be used to
> find out? (or setting both READ and RCV parameters and messages in the
> same function call above) If not, how to find out that the read part of
> the pipe has been closed (within hurdselect, not the application)

You seem to be thinking about this at the wrong level.  That call has to do
with the io RPCs we're making.  Whatever happens to a pipe doesn't change
what kind of RPCs the ports at either end accept.  It's simply up to the io
server (pflocal in this case) to implement the appropriate semantics.  When
the writing end of a pipe or socket is closed, any future io_read calls
should return the EOF indication and any future io_select calls inquiring
about reading should report it as immediately readable.  If any such calls
are already blocked in pflocal when the writing end is closed, they should
immediately wake up and return those results.  That means that select/poll
will get an io_select_reply message from that server.


Thanks,
Roland