Thread: [naviserver-devel] task backport?

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Interesting...
What is a "task" (in a nutshell)?

Cheers
Zoran

On 1/4/06, Zoran Vasiljevic <zv...@ar...> wrote:
> Interesting...
> What is a "task" (in a nutshell)?
>

It's an API for async network IO.  You create a queue which is managed
by a single thread.  You add tasks to the queue.  A task is a callback
and a socket event.  The queue thread monitors all sockets for events
(readable/writeable) and then runs the callbacks.

Am 04.01.2006 um 11:35 schrieb Stephen Deasey:

>  The queue thread monitors all sockets for events
> (readable/writeable) and then runs the callbacks.
>
>

Isn't this what the driver thread is doing?
Is this a potential replacement/abstraction
of the driver thread?

On 1/4/06, Zoran Vasiljevic <zv...@ar...> wrote:
>
> Am 04.01.2006 um 11:35 schrieb Stephen Deasey:
>
> >  The queue thread monitors all sockets for events
> > (readable/writeable) and then runs the callbacks.
> >
> >
>
> Isn't this what the driver thread is doing?
> Is this a potential replacement/abstraction
> of the driver thread?
>

Maybe.  I haven't looked closely enough yet.

I believe poll can be used on any file descriptor, not only sockets.

It is generic socket/fds callback infrastructure, it is very similar to 
socket callbacks we already have in sockcallback.c.

Does not make sense to have both, they duplicating each other

Stephen Deasey wrote:
> On 1/4/06, Zoran Vasiljevic <zv...@ar...> wrote:
> 
>>Am 04.01.2006 um 11:35 schrieb Stephen Deasey:
>>
>>
>>> The queue thread monitors all sockets for events
>>>(readable/writeable) and then runs the callbacks.
>>>
>>>
>>
>>Isn't this what the driver thread is doing?
>>Is this a potential replacement/abstraction
>>of the driver thread?
>>
> 
> 
> Maybe.  I haven't looked closely enough yet.
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> 

-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

Am 04.01.2006 um 16:10 schrieb Vlad Seryakov:

> I believe poll can be used on any file descriptor, not only sockets.
>
> It is generic socket/fds callback infrastructure, it is very  
> similar to socket callbacks we already have in sockcallback.c.
>
> Does not make sense to have both, they duplicating each other

Hm... on the first glance, yes... I think the benefit of
"task" interaface is that it's more genral in terms of
the API. Actually, one could re-write the latter with the
former, as I can see.

The sockcallback exports just two/three calls:
Ns_SockCallback
Ns_SockCancelCallback
Ns_SockCancelCallbackEx

whereas the task is much more elaborate.

The question is who would benefit from task interface?
Are there any immediate ideas?
For what they (AS) wrote it for?
What can it do what Tcl event loop can't?

Zoran

As far as i remember JimD rewrote ns_http using new tasks API, but other 
than that i do not know where/how tasks API is used.

Tasks API is good,  i agree it is more generic and Tcl interface can be 
built around it so instead of using Tcl event loop it will be possible 
to use tasks. with Tcl main loop you need to spawn separate threads if 
you need multiple tasks to be queued from different threads/places.

Zoran Vasiljevic wrote:
> 
> Am 04.01.2006 um 16:10 schrieb Vlad Seryakov:
> 
>> I believe poll can be used on any file descriptor, not only sockets.
>>
>> It is generic socket/fds callback infrastructure, it is very  similar 
>> to socket callbacks we already have in sockcallback.c.
>>
>> Does not make sense to have both, they duplicating each other
> 
> 
> Hm... on the first glance, yes... I think the benefit of
> "task" interaface is that it's more genral in terms of
> the API. Actually, one could re-write the latter with the
> former, as I can see.
> 
> The sockcallback exports just two/three calls:
> Ns_SockCallback
> Ns_SockCancelCallback
> Ns_SockCancelCallbackEx
> 
> whereas the task is much more elaborate.
> 
> The question is who would benefit from task interface?
> Are there any immediate ideas?
> For what they (AS) wrote it for?
> What can it do what Tcl event loop can't?
> 
> Zoran
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> 

-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

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.=20
If it did, we wouldn't have to talk about aio_read()    :-)

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.

Cheers
Zoran

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 *=3D 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

Make sure you've read the C10K page:

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

Am 06.01.2006 um 20:18 schrieb Stephen Deasey:
> Don't believe everything you read.  Man pages are often little more
> than hopes and dreams...
>

LOL!

> 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
>

I will read this.

>
> Make sure you've read the C10K page:
>
> http://www.kegel.com/c10k.html
>

Most interesting. I will spend some thime on this doc!

But then... what about Tcl event-loop? With the above,
you indicate that their event-loop model will  not
really work with diskfiles?

Zoran

>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through =20
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD =20
> SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dclick
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

> Make sure you've read the C10K page:
>
> http://www.kegel.com/c10k.html
>
>   
you might want to check lighthttp with its benchmarks, it tried a lot to 
improve throughput based on the c10k tipps, including epoll for linux. 
it is at least a nice reference.

http://www.lighttpd.net/

-gustaf

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

Am 04.01.2006 um 11:35 schrieb Stephen Deasey:

> It's an API for async network IO.  You create a queue which is managed
> by a single thread.  You add tasks to the queue.  A task is a callback
> and a socket event.  The queue thread monitors all sockets for events
> (readable/writeable) and then runs the callbacks.

Thanks. Need it be a socket or can it handle any open descriptor?

On 1/4/06, Zoran Vasiljevic <zv...@ar...> wrote:
>
> Am 04.01.2006 um 11:35 schrieb Stephen Deasey:
>
> > It's an API for async network IO.  You create a queue which is managed
> > by a single thread.  You add tasks to the queue.  A task is a callback
> > and a socket event.  The queue thread monitors all sockets for events
> > (readable/writeable) and then runs the callbacks.
>
> Thanks. Need it be a socket or can it handle any open descriptor?
>

Has to be a socket, it's a limitation of poll().   :-(

Thread: [naviserver-devel] task backport?

NaviServer, a high performance web server written in C and Tcl

naviserver-devel