Re: aio_read/write versus O_NONBLOCK

phil-news-nospam@xxxxxxxx writes:
On Thu, 15 May 2008 18:55:43 GMT Scott Lurndal <scott@xxxxxxxxxxxxx> wrote:
| phil-news-nospam@xxxxxxxx writes:
|>On Wed, 14 May 2008 00:13:59 -0400 Barry Margolin <barmar@xxxxxxxxxxxx> wrote:
|>| In article
|>| <fe463120-697d-4100-9ca8-b74083491664@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
|>| RazvanD <razvand@xxxxxxxxx> wrote:
|>|
|>|> Hi!
|>|>
|>|> Could someone point me to some articles or give me some hints on the
|>|> advantages/disadvantages of asynchronous operations on files (aio_read/
|>|> aio_read) versus normal operations (read/write) used with O_NONBLOCK
|>|> when opening a file.
|>|>
|>|> aio_read/aio_write are indeed more flexible. But, at least on Linux/
|>|> glibc, they are implemented using POSIX threads. Wouldn't a carefully
|>|> designed program using O_NONBLOCK for files best a program using
|>|> aio_read/aio_write? I think my question should be: are asynchronous I/
|>|> O operations only more flexible or are they also faster?
|>|
|>| I'm not certain about Linux, but on many systems O_NONBLOCK has no
|>| effect on ordinary file streams.
|>
|>It has not had any effect on ordinary file streams in Linux in the programs
|>I have written that tried it (a couple of them).
|>
|
| It's pretty much of a waste of time. O_NONBLOCK doesn't make any sense
| for file descriptors that can't block on a read (i.e. disk-based files).

Could you explain why you believe that to be the case?


It's simple. The disk is always there, so a read must always complete
in a bounded time. O_NONBLOCK was added to Unix to handle cases where
a blocking read can be unbounded (serial ports, parallel ports, network
ports).

Just like poll(2) and select(2) always rval a disk-based file descriptor
as readable and writeable, if they support disk-based files at all.

scott
.

Relevant Pages

  • Re: aio_read/write versus O_NONBLOCK
    ... |>| for file descriptors that can't block on a read. ... The disk is always there, so a read must always complete ... | a blocking read can be unbounded (serial ports, parallel ports, network ... But a bounded time is not zero time. ...
    (comp.unix.programmer)
  • Re: too many open file descriptors messages since bind 9.4.2-P1 (port dns94)
    ... Since i updated my FreeBSD 6.3 dns server with the latest bind version in the ports (dns/bind94) my system is flooding my log with "too many open file descriptors" messages. ...
    (freebsd-net)
  • Re: bind: Address already in use
    ... >/proc looking for the ports in question. ... Current rlimit: 1024 file descriptors ... There appears to be two copies of inetd running ...
    (comp.unix.solaris)