|
|
@ -462,8 +462,8 @@ While nominally embeddable in other event loops, this doesn't work |
|
|
|
everywhere, so you might need to test for this. And since it is broken |
|
|
|
almost everywhere, you should only use it when you have a lot of sockets |
|
|
|
(for which it usually works), by embedding it into another event loop |
|
|
|
(e.g. C<EVBACKEND_SELECT> or C<EVBACKEND_POLL>) and, did I mention it, |
|
|
|
using it only for sockets. |
|
|
|
(e.g. C<EVBACKEND_SELECT> or C<EVBACKEND_POLL> (but C<poll> is of course |
|
|
|
also broken on OS X)) and, did I mention it, using it only for sockets. |
|
|
|
|
|
|
|
This backend maps C<EV_READ> into an C<EVFILT_READ> kevent with |
|
|
|
C<NOTE_EOF>, and C<EV_WRITE> into an C<EVFILT_WRITE> kevent with |
|
|
@ -2430,24 +2430,20 @@ and even priorities and idle watchers might have too much overhead. In |
|
|
|
this case you would put all the high priority stuff in one loop and all |
|
|
|
the rest in a second one, and embed the second one in the first. |
|
|
|
|
|
|
|
As long as the watcher is active, the callback will be invoked every time |
|
|
|
there might be events pending in the embedded loop. The callback must then |
|
|
|
call C<ev_embed_sweep (mainloop, watcher)> to make a single sweep and invoke |
|
|
|
their callbacks (you could also start an idle watcher to give the embedded |
|
|
|
loop strictly lower priority for example). You can also set the callback |
|
|
|
to C<0>, in which case the embed watcher will automatically execute the |
|
|
|
embedded loop sweep. |
|
|
|
|
|
|
|
As long as the watcher is started it will automatically handle events. The |
|
|
|
callback will be invoked whenever some events have been handled. You can |
|
|
|
set the callback to C<0> to avoid having to specify one if you are not |
|
|
|
interested in that. |
|
|
|
|
|
|
|
Also, there have not currently been made special provisions for forking: |
|
|
|
when you fork, you not only have to call C<ev_loop_fork> on both loops, |
|
|
|
but you will also have to stop and restart any C<ev_embed> watchers |
|
|
|
yourself - but you can use a fork watcher to handle this automatically, |
|
|
|
and future versions of libev might do just that. |
|
|
|
As long as the watcher is active, the callback will be invoked every |
|
|
|
time there might be events pending in the embedded loop. The callback |
|
|
|
must then call C<ev_embed_sweep (mainloop, watcher)> to make a single |
|
|
|
sweep and invoke their callbacks (the callback doesn't need to invoke the |
|
|
|
C<ev_embed_sweep> function directly, it could also start an idle watcher |
|
|
|
to give the embedded loop strictly lower priority for example). |
|
|
|
|
|
|
|
You can also set the callback to C<0>, in which case the embed watcher |
|
|
|
will automatically execute the embedded loop sweep whenever necessary. |
|
|
|
|
|
|
|
Fork detection will be handled transparently while the C<ev_embed> watcher |
|
|
|
is active, i.e., the embedded loop will automatically be forked when the |
|
|
|
embedding loop forks. In other cases, the user is responsible for calling |
|
|
|
C<ev_loop_fork> on the embedded loop. |
|
|
|
|
|
|
|
Unfortunately, not all backends are embeddable: only the ones returned by |
|
|
|
C<ev_embeddable_backends> are, which, unfortunately, does not include any |
|
|
|