Re: [PATCH] /dev/epoll update ...

[ebiederm@xmission.com (Eric W. Biederman)]

Davide Libenzi <davidel@xmailserver.org> writes:

> On 20-Sep-2001 Christopher K. St. John wrote:
> > Davide Libenzi wrote:
> >> 
> >> Here are examples basic functions when used with
> >> coroutines.
> >>
> >  
> >  I think all might be made clear if you did a quick
> > test harness that didn't use coroutines. I'm guessing
> > the vast majority of potential users will not be using
> > a coroutine library.
> > 
> >  On "nio-improve" page, you've got:
> > 
> >         for (;;) {
> >           evp.ep_timeout = STD_SCHED_TIMEOUT;
> >           evp.ep_resoff = 0;
> >           nfds = ioctl(kdpfd, EP_POLL, &evp);
> >           pfds = (struct pollfd *) (map + evp.ep_resoff);
> >           for (ii = 0; ii < nfds; ii++, pfds++) {
> >              ...
> >           }
> >         }
> 
> Coroutines or not, this does not change the picture.
> All multiplexed servers have an IO driven scheduler that calls
> code sections based on the fd.
> Obviously if you've a one-thread-per-socket model, epoll is not your answer.

A couroutine is a thread, the two terms are synonyms.  Generally
coroutines refer to threads with a high volumne of commniucation
between them.  And the terms come from different programming groups.

However a fully cooperative thread (as is implemented in the current
coroutine library) can be quite cheap, and is a easy way to implement
a state machine.  A pure state machine will have a smaller data
footprint than the stack of a cooperative thread, but otherwise
the concepts are pretty much the same.  Language support for
cooperative threads, so you could verify you wouldn't overflow your
stack would be very nice. 

So epoll is a good solution if you have a one-thread-per-socket model,
and you are doing cooperative threads.  The thread being used here is
simply a shortcut to writing a state machine.

Eric