Date: Tue, 9 Dec 1997 00:56:36 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Cc: tlambert@primenet.com, julian@whistle.com, hackers@FreeBSD.ORG Subject: Re: Why FIONREAD has no dual for write ? Message-ID: <199712090056.RAA24076@usr01.primenet.com> In-Reply-To: <199712081945.UAA29200@labinfo.iet.unipi.it> from "Luigi Rizzo" at Dec 8, 97 08:45:09 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > It's short, it's elegant, and you can still use "select()" for the > > readability/writeability to avoid turning the program into a polling > > loop. > > I agree with the above, except that it does not work in all situations. > E.g. I am not sure but does select() guarantee that you don't > end up writing/reading one byte at a time ? I know in practice things > are different, but there is no standard behaviour I think, so the risk > is still there. In the audio driver I had to modify the behaviour of > select() (block size) using a separate ioctl(). Select just returns true when *any* buffer space is available. If the driver needs to be fed at a certain block size, then it should free up that much space at a time. In practice, this frequently means that you double-buffer in the driver using buffers owned by the driver, and rely on driver access policy to ensure against multiple writer problems (these should not be an issue in any case, if you maintain ordering guarantees between the writers -- something you have to do anyway with any order dependent data). For Select on read, it returns true when *any* data is available. In general, you would read with a vmin of one and a small vtime to allow streaming. Otherwise, you would read on a non-blocking descriptor, and expect some number of bytes less than or equal to the read amount to be returned. In practice, your process won't be scheduled until some interval after it is ready to run, and you should get good effective streaming of reads by virtue of this. > Plus there are apps which want only to check the status of the queue in > a descriptor without actually doing the I/O, for whatever reason they > like. Well, for these apps, you could designate them "real time priority" so they have "first dibs". But you are not guaranteed, without hard real time, that you will actually be scheduled in time. Multiple readers/writers could damage wakeup order, and you'd still have the race conditions. Probably your too-sensitive applications need to be written as drivers, not applications. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712090056.RAA24076>