Browse Source

*** empty log message ***

master
Marc Alexander Lehmann 13 years ago
parent
commit
68e7645ceb
  1. 3
      Changes
  2. 5
      ev.c
  3. 36
      ev.pod

3
Changes

@ -7,6 +7,8 @@ Revision history for libev, a high-performance and full-featured event loop.
- assume negative return values != -1 signals success of port_getn
(http://cvs.epicsol.org/cgi/viewcvs.cgi/epic5/source/newio.c?rev=1.52)
(no known failure reports, but it doesn't hurt).
- fork detection in ev_embed now stops and restarts the watcher
automatically.
- EXPERIMENTAL: default the method to operator () in ev++.h,
to make it nicer to use functors (requested by Benedek László).
- fixed const object callbacks in ev++.h.
@ -16,6 +18,7 @@ Revision history for libev, a high-performance and full-featured event loop.
- inotify watchers could be leaked under certain circumstances.
- OS X 10.5 is actually even more broken than earlier versions,
so fall back to select on that piece of garbage.
- fixed some weirdness in the ev_embed documentation.
3.49 Wed Nov 19 11:26:53 CET 2008
- ev_stat watchers will now use inotify as a mere hint on

5
ev.c

@ -2907,11 +2907,16 @@ embed_fork_cb (EV_P_ ev_fork *fork_w, int revents)
{
ev_embed *w = (ev_embed *)(((char *)fork_w) - offsetof (ev_embed, fork));
ev_embed_stop (EV_A_ w);
{
struct ev_loop *loop = w->other;
ev_loop_fork (EV_A);
ev_loop (EV_A_ EVLOOP_NONBLOCK);
}
ev_embed_start (EV_A_ w);
}
#if 0

36
ev.pod

@ -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

Loading…
Cancel
Save