From 23068c2bb1e8510d27176a3c3c79d55656502441 Mon Sep 17 00:00:00 2001 From: root Date: Tue, 5 Jul 2011 17:05:54 +0000 Subject: *** empty log message *** --- eio.pod | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/eio.pod b/eio.pod index 3cffbe8..31933fe 100644 --- a/eio.pod +++ b/eio.pod @@ -132,9 +132,9 @@ If C is configured to not handle all results in one go (i.e. it returns C<-1>) then you should start an idle watcher that calls C until it returns something C. -A full-featured wrapper would look as follows (if C is handling -all requests, it can of course be simplified a lot by removing the idle -watcher logic): +A full-featured conenctor between libeio and libev would look as follows +(if C is handling all requests, it can of course be simplified a +lot by removing the idle watcher logic): static struct ev_loop *loop; static ev_idle repeat_watcher; @@ -180,9 +180,12 @@ For most other event loops, you would typically use a pipe - the event loop should be told to wait for read readiness on the read end. In C you would write a single byte, in C you would try to read that byte, and in the callback for the read end, you would call -C. The race is avoided here because the event loop should invoke -your callback again and again until the byte has been read (as the pipe -read callback does not read it, only C). +C. + +You don't have to take special care in the case C doesn't handle +all requests, as the done callback will not be invoked, so the event loop +will still signal readyness for the pipe until I results have been +processed. =head1 HIGH LEVEL REQUEST API -- cgit v1.2.3