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)
