On Thu, Aug 24, 2000 at 11:45:35AM -0400, Joshua N Pritikin <[EMAIL PROTECTED]>
wrote:
> > Just as linux: you clone/block/signal (i am not talking about pthreads). Its
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 ;)
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)
This should be very efficient, and automatically affls 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).
> 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!
--
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
