Date: Mon, 8 Dec 1997 09:35:06 +0100 (MET) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: julian@whistle.com (Julian Elischer) Cc: hackers@FreeBSD.ORG Subject: Re: Why FIONREAD has no dual for write ? Message-ID: <199712080835.JAA28372@labinfo.iet.unipi.it> In-Reply-To: <Pine.BSF.3.95.971207230045.20612F-100000@current1.whistle.com> from "Julian Elischer" at Dec 7, 97 11:07:05 pm
next in thread | previous in thread | raw e-mail | index | archive | help
[first of all, thanks for answering...] > > FIONREAD tells you how many bytes you can read before blocking. > > > > There is no FIONWRITE call (how many bytes you can write before ... > but it could change between the time you do that call and the time that > doo the write (you could be sharing a file descriptor, or you could be > sharing a device) so you may have to handle the blocking write anyhow. same for FIONREAD, which is there. Many programs are written under the assumption that there is no sharing of descriptors and they will fail poorly when this happens. E.g. can you tell me how many device drivers implement mutual exclusion on blocking calls, rather than limiting to allow only a single open() and then hope that fork()ed processes synchronize in using the inherited device ? The discussion was on this forum some time ago and the conclusion was more or less 'if they are looking for trouble let them have them' > > And there is no FIOWQUEUED call (or similar name) to tell how many > > bytes are queued for I/O on a given descriptor. > > true > do you really thing this is useful? ... > possibly there might be a more DIRECT way of doing what you want with > appropriate device driver. ... > Well, I guess it wouldn't help any programs with aims of being > portable. there are direct ways in each driver, but each driver implements almost exactly the same function using a different name. This way you not only lose portability across different architectures, you also lose portability across different drivers. As an example, I implemented "FIONWRITE" and "FIOWQUEUED" in the audio driver, but decided to call them AIONWRITE and AIOSYNC to avoid name clashes with FIO* (and complaints from the censors). Hannu just implemented "FIOWQUEUED" in OSS, calling it SNDCTL_DSP_GETODELAY. I am sure there are equivalent calls with several other audio drivers, just that I have no idea what are they called. What do we gain from this ? We have a 20 years old interface (FIONREAD..) and I can understand that at that time some needs (e.g. synchronizing streams) were simply not there. Now we have new requirements and apps, and it would be appropriate to work on a common interface which is as device independent as possible. I don't think one has to worry too much about portability here since the alternative is the use of non-standardized functions anyways. > If you can get iti past the censors then I guess it would be ok, but > I can imagine a few screams from some quarters. Yes, but _who_ are the censors and whom should I ask ? This is not a FreeBSD only thing I imagine... Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712080835.JAA28372>