> 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
