Re: kqueue

On Thu, Aug 24, 2000 at 06:13:03PM +0200, [email protected] wrote:
> I forgot to mention that there are a lot of other ways to implement asynch
> i/o, for example you could just transfer the data inside the signal
> handler ;)

THAT's portable.  :-)

> However, as for Event I think one could implement the internal event loop
> using the kernel event queue by doing this (this should be portable with
> small changes to solaris and other unices, maybe Uri can verify this? It is,
> however, the same as on BSD AFAIK):
> 
> setup-phase:
>    block our rt-signal (or SIGIO)
>    for every filehandle
>       fcntl fh, F_SETSIG, <our predefined rt-signal OR SIGIO as fallback>
>       fcntl fh, F_SETFL, O_ASYNC
> 
> then the event loop becomes:
>    sigtimedwait (signals-to-wait-for, &mysiginfo, timeval);
>    if (signal is our rt-signal/SIGIO)
>      if (mysiginfo is valid)
>        dispatch event
>      else
>        use old-fashioned select to get events
>    elseif signal received?
>      dispatch signal handler
>    else
>      timeout (dispatch timer events)

Sure, the hard part is working code.  ;-)

> This should be very efficient, and automatically falls back to seletc when
> the number of events becomes too large for the event queue. The phhttpd
> package does use this exact technique.
> 
> (Of course one must be careful, as not every kernel/libc combination
> supports this, but this shouldn't be much different than checking for
> poll/select features).

If they got it to work then perhaps we can borrow some code.

> > I find myself slowly gravitating away from software (and towards
> > trading).  :-)
> 
> That's bad, the world depends on a very active Event maintainer, as in no
> far future, Event will be a standard perl core module!! Or so I think!

Well, I haven't disappeared yet and I'm sure that a new maintainer could
be procured, if necessary.

-- 
May the best description of competition prevail.
      (via, but not speaking for Deutsche Bank)