Re: aio_read/write versus O_NONBLOCK

On Tue, 20 May 2008 23:49:36 GMT Scott Lurndal <scott@xxxxxxxxxxxxx> wrote:
| phil-news-nospam@xxxxxxxx writes:
|>On Thu, 15 May 2008 21:56:27 GMT Scott Lurndal <scott@xxxxxxxxxxxxx> wrote:
|>| 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).
|>
|>But a bounded time is not zero time. There are things that can be done
|>while a disk is being read.
|
| I don't think you really understand how file-based I/O works in linux.
| In the majority of cases, by the time you issue the read(2)/pread(2) system
| call, it is likely that the data has already been read from the disk.

Why do you not think I really understand how file-based I/O works in Linux?
When the data is already read from disk, then read(2) will be expected to
not return EAGAIN when the descriptor is set to O_NONBLOCK.


| In any case, what you want is asychronous I/O, rather than non-blocking I/O.
|
| See aio_read/aio_write/lio_listio.

So how does one make a process wait for these asyncronous I/O requests AND AT
THE SAME TIME ALSO wait for descriptors that represent other things such as
sockets? Function aio_suspend(3) does not seem to be the way to do this.


| Btw, if you're copying one file to another, use mmap/madvise
| not read/pread/write/pwrite.

That's what I'm doing now. But msync(2) does not provide a non-blocking way to
determine I/O completion. That's why I need to find something better. And the
O_NONBLOCK and poll(2) way would be just right if it were allowed for disk files
and devices.

--
|WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
| by the abuse department, bellsouth.net is blocked. If you post to |
| Usenet from these places, find another Usenet provider ASAP. |
| Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |
.

Relevant Pages

  • Re: aio_read/write versus O_NONBLOCK
    ... |>|>It has not had any effect on ordinary file streams in Linux in the programs ... The disk is always there, so a read must always complete ... | a blocking read can be unbounded (serial ports, parallel ports, network ... In any case, what you want is asychronous I/O, rather than non-blocking I/O. ...
    (comp.unix.programmer)
  • Re: pitiful performance of an SATA150 drive
    ... On FreeBSD, the disk device nodes provide unbuffered disk access, under the assumption that consumers will be providing their own caching, or they wouldn't be using the direct disk interface. ... In Linux, they probably still maintain the character vs. block distinction, in which case one may well offer significant caching, which will show up on micro-benchmarks that issue small I/O sizes or behave relatively unintelligently. ...
    (freebsd-current)
  • Re: Programming Question: non-blocking I/O
    ... DM> I'm porting an app from Windows to Linux and have not yet found how to ... DM> How is this done under Linux? ... now any sort of background processing for disk I/O. ... I/O is always synchronous and effectively instantaneous -- user process ...
    (comp.os.linux.misc)
  • Re: Losing clock ticks (Was: Severe time drift for Undisciplined Local Clock)
    ... ticks if it is doing other things that require disk I/O.) ... It's a known problem with some versions of both Linux and Windows. ...
    (comp.protocols.time.ntp)
  • Re: Panasonic HD Recorders - What disk format?
    ... The earlier part of this is more about what may be Linux partitioning, ... might be possible to present the recorder with a larger disk already ... Most DOS/Windows utilities such as FDisk, Ghost, and Partition Magic Pro ... prompts to format it. ...
    (alt.os.linux)