diff options
author | root <root> | 2007-12-08 22:11:14 +0000 |
---|---|---|
committer | root <root> | 2007-12-08 22:11:14 +0000 |
commit | fe7222913a6e42b65bfd92bc38479714316cfaf3 (patch) | |
tree | 084ead8c8227fb6bcb551f089cbfcdc563e7ac03 /ev.pod | |
parent | 09c28a9820828432b5ced0a8f2b05c56213690fc (diff) |
*** empty log message ***
Diffstat (limited to 'ev.pod')
-rw-r--r-- | ev.pod | 13 |
1 files changed, 12 insertions, 1 deletions
@@ -488,8 +488,9 @@ usually a better approach for this kind of thing. Here are the gory details of what C<ev_loop> does: + - Before the first iteration, call any pending watchers. * If there are no active watchers (reference count is zero), return. - - Queue prepare watchers and then call all outstanding watchers. + - Queue all prepare watchers and then call all outstanding watchers. - If we have been forked, recreate the kernel state. - Update the kernel state with all outstanding changes. - Update the "event loop time". @@ -1483,6 +1484,16 @@ of lower priority, but only once, using idle watchers to keep the event loop from blocking if lower-priority coroutines are active, thus mapping low-priority coroutines to idle/background tasks). +It is recommended to give C<ev_check> watchers highest (C<EV_MAXPRI>) +priority, to ensure that they are being run before any other watchers +after the poll. Also, C<ev_check> watchers (and C<ev_prepare> watchers, +too) should not activate ("feed") events into libev. While libev fully +supports this, they will be called before other C<ev_check> watchers did +their job. As C<ev_check> watchers are often used to embed other event +loops those other event loops might be in an unusable state until their +C<ev_check> watcher ran (always remind yourself to coexist peacefully with +others). + =over 4 =item ev_prepare_init (ev_prepare *, callback) |