Am 06.01.2006 um 20:18 schrieb Stephen Deasey:

On 1/6/06, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:

Am 04.01.2006 um 20:40 schrieb Stephen Deasey:

On 1/4/06, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
I believe poll can be used on any file descriptor, not only sockets.


It doesn't work if the file descriptor is backed by a file on disk.
If it did, we wouldn't have to talk about aio_read()    :-)



Hmmm...

SYNOPSIS
      #include <poll.h>

      int
      poll(struct pollfd *fds, nfds_t nfds, int timeout);

DESCRIPTION
      Poll() examines a set of file descriptors to see if some of
them are
      ready for I/O or if certain events have occurred on them.  The
fds argu-
      ment is a pointer to an array of pollfd structures as defined
in <poll.h>
      (shown below).  The nfds argument determines the size of the
fds array.

I believe that poll should work with files as well. That is I can't
find no reason why it shoudn't by reading the man and inspecting
the "poll" emulation we have in nsd/unix.c. Tcl also uses the similar
machinery to implement non-blocking read/write to files (see below).

The AIO comes into place where you basically have one more layer
of processing in the kernel which handles your dispatched events
and let you asynchronously inspect them, cancel them etc.

So: poll + tcl_event_loop *= AIO. Unfortunately this works only
for single-threaded apps as tcl_event_loop only handles events
from the current thread. Roughly. As AIO is normally done by the
kernel it is/shouldbe much more faster.
One can always simulate the aio by a specialized thread and non- blocking
read/writing. But having this all done for you in the kernel (as
in some "proper" implementation) things should be simpler to implement
and faster in deployment.


Don't believe everything you read.  Man pages are often little more
than hopes and dreams...

In practice poll() does not work with files backed by disk.  Even the
Open Group specifies that "Regular files always poll TRUE for reading
and writing."

http://www.opengroup.org/onlinepubs/007908799/xsh/poll.html
This is what you ment, right?

      Regular files always poll TRUE for reading and writing.
It makes me hard to believe that a write or read from a
slow filesystem like floppy-disk or an NFS-mount is always
readable or writable! It just makes no sense to me.


Make sure you've read the C10K page:

http://www.kegel.com/c10k.html

This is also what you ment, right?

Use nonblocking calls (e.g. write() on a socket set to O_NONBLOCK) to start I/O, and readiness notification (e.g. poll() or /dev/poll) to know when it's OK to start the next I/O on that channel. Generally only usable with network I/O, not disk I/O. Use asynchronous calls (e.g. aio_write()) to start I/O, and completion notification
      (e.g. signals or completion ports) to know when the I/O finishes.
      Good for both network and disk I/O.

Again "only usable with network I/O, not disk I/O" is here. That means
people wanted to utilitze non-blocking IO to disk files (possibly on
the slow filesystems like DVD-RAM's, floppies, NFS etc.) have no other
possiblity to write non-blocking code by poll/select and non-blocking write
except using AIO?

This is a hard pill to swallow. That would mean if I'm to write a 1MB
file on a floppy, my Tcl program will be permanently busy with that one
operation? Hmmm... I must try this. I have no floppy on my Mac but
I can use a mounted DVD-RAM which is almost equally slow and a Tcl
program in event loop and measure times between write events...

Zoran


Reply via email to