Back in late March, I wrote here (under the Subject: Re: flock(2): locking against itself?) about a locking issue, which drifted into discussing per-descriptor state versus per-open state (thank you dholland for that phrasing!) versus backing-object state. In particular, someone (I forget who) said that non-blocking really should be per-operation rather than being state anywhere.
That's correct, but, thinking about it since then, that is not as easy as one might wish, because there are quite a number of calls that can be affected. (Offhand: {,p}{read,write}{,v}, connect, accept, {send,recv}{,msg}, sendto, recvfrom. There are probably others, but this is sixteen already - though I'm not sure p{read,write}{,v} need the option; are there any seekable objects on which non-blocking is significant?) Some of these, such as send*, already have a flags argument that could grow a new bit to indicate nonblocking, but the rest - more than half - would need to have an alternative version created with a flags field, or some such. While hardly impossible, this gets annoying, and indeed might be best addressed by (to use read() as an example) making the real syscall backing read() always take a flags argument, with the libc stub supplying a fixed value for the flags when the flagless API is called. This is pushing towards making it per-descriptor state. At present, the versions I have don't have anything but close-on-exec as true per-descriptor state. A quick look at 9.1 and cvsweb.netbsd.org (which, mirabilu visu, actually works for me, unlike www.netbsd.org and mail-index.netbsd.org) sys/sys/filedesc.h makes me think that that's true of them as well. For backward compatibility, I would be inclined to leave the existing mechanisms in place, theoretically to be removed eventually. This also means divorcing "non-blocking open" from "non-blocking I/O after open". So: does anyone have any comments on the above analysis, or thoughts on good, bad, or even just notable effects making it real per-descriptor state might have? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B