Re: [naviserver-devel] task backport?

[Zoran V. <zv...@ar...>]

Am 06.01.2006 um 20:18 schrieb Stephen Deasey:

> On 1/6/06, Zoran Vasiljevic <zv...@ar...> wrote:
>>
>> Am 04.01.2006 um 20:40 schrieb Stephen Deasey:
>>
>>> On 1/4/06, Vlad Seryakov <vl...@cr...> 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