Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msunews!agate!howland.reston.ans.net!spool.mu.edu!olivea!nntp-sc.barrnet.net!netapp.com!netapp.com!not-for-mail From: guy@netapp.com (Guy Harris) Newsgroups: comp.unix.bsd Subject: Re: Why select() returns ``exceptional'' for files? Date: 21 Jan 1995 18:37:10 -0800 Organization: Network Appliance Corporation Lines: 47 Message-ID: <3fsgcm$7ph@nova.netapp.com> References: <3fois1$5d5@shore.shore.net> <3fpssn$2gk@nova.netapp.com> <3frbtr$9kq@shore.shore.net> NNTP-Posting-Host: 192.9.200.13 Robert Withrow <witr@rwwa.com> wrote: >Well... Usually an ``exceptional condition'' means something bad >happened. Umm, I'm not sure I'd classify an out-of-band message on a socket as "something bad"; at times, I'd classify the *lack* of such a message as "something bad", e.g. if I'm rlogged into some machine, change the size of my window, and no out-of-band message gets sent to the "rlogin" daemon on the machine into which I'm rlogged telling it to change the tty driver's notion of the screen size, I'd consider that somewhat bad. I.e., no, an "exceptional condition" doesn't "usually" mean "something bad happened"; it means something *out of the ordinary* happened - for example, on a socket, an "exceptional condition" is reported for out-of-band data. >It complicates things when you have to take special >actions based on the kind of thing you are select()ing on. This >means that one must know what kind of fd you have before you >decide to put it in the exceptions bit vector. I suspect that the lack of a definition of "exceptional condition" that applies to all file descriptors is deliberate; not all file descriptors refer to the exact same type of thing, and there are times when an application wants to, for example, be notified that some particular event, of a type specific to the object to which some file descriptor refers, has occurred. Given that exceptional conditions are *not* defined in some form independent of the object to which a file descriptor refers, the only reason why you'd *want* to put an FD in the exceptions bit vector would be if you knew that the FD in question could *get* an exceptional condition of a type in which your program would be interested - i.e., the only reason why you'd *want* to put an FD in the exceptions bit vector would be if you knew what kind of FD you had. There's no reason to put them in the exceptions bit vector if you don't know what kind of FD you have (which implies that you don't care what kind of FD you have). >I think that stinks, but what do I know... Complaining that exceptional conditions are dependent on the type of object to which a file descriptor refers seems to me to be like complaining that the behavior of an "ioctl" is dependent on the type of object to which a file descriptor refers; as far as I know, both were *intended* to be object-type dependent, so that an application could do particular object-type-dependent things to particular types of objects.