on 21/01/2009 16:05 Robert Watson said the following: > > On Wed, 21 Jan 2009, Andriy Gapon wrote: >> I also would like the driver to provide a select capability quite >> similar to that of network (e.g. TCP) sockets using d_poll. I.e. a >> userland program should be able to query when it can write data to the >> device without blocking and when it can read data without blocking, plus >> when an error occurred in the device/driver, so there is no point in >> further waiting. >> At this moment I am thoroughly confused by meaning of various event >> masks described in poll(2). E.g. what is normal priority, non-zero >> priority and high priority. >> Which flags should I care about if all data is the same priority for me? >> Which flag(s) should I set when I'd like to communicate an error >> condition (e.g. similar to TCP connection reset)? > > I find that the description of the polling flags is at best confusing in > both man pages and specifications. The best bet is to look at the > existing TCP semantics, which are basically defined in sopoll_generic(): [snip] > A few observations: > > - Neither POLLHUP nor POLLERR appear to be implemented for sockets (all > protocols use sopoll_generic in practice). This is surprising given the > wording in the poll(2) man page. > > - Make sure to distinguish POLLIN and POLLINIGNEOF -- the difference > between > soreadable() and the test in POLLIGNEOF is that POLLIN also considers > SBS_CANTRCVMORE (i.e., at least half-close in the receive direction) but > POLLIGNEOF doesn't. > > I think Kostik's pointer to the pipe_poll() code is a good one, but if > you're looking to emulate TCP semantics a bit more exactly, these > differences should be taken into account.
Robert, Kostik, thank you for the great pointers. >From previous network programming I recall that if an error occurs on a TCP socket then select(2) marks the socket as available for reading (and probably for writing too), then a subsequent operation gets actual error code. I think that maybe this was the only way to do it in select-only days. I am a little bit confused about exceptfds parameter of select, the manual page says "The only exceptional condition detectable is out-of-band data received on a socket" and I am not sure what that would be for TCP and how that could be used in practice. Anyway, I'd probably stick to the same strategy - mark the device as available for reading and writing if an error occurs and then return error code in actual read/write. -- Andriy Gapon _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
