… | |
… | |
370 | When this flag is specified, then libev will not attempt to use the |
370 | When this flag is specified, then libev will not attempt to use the |
371 | I<inotify> API for it's C<ev_stat> watchers. Apart from debugging and |
371 | I<inotify> API for it's C<ev_stat> watchers. Apart from debugging and |
372 | testing, this flag can be useful to conserve inotify file descriptors, as |
372 | testing, this flag can be useful to conserve inotify file descriptors, as |
373 | otherwise each loop using C<ev_stat> watchers consumes one inotify handle. |
373 | otherwise each loop using C<ev_stat> watchers consumes one inotify handle. |
374 | |
374 | |
375 | =item C<EVFLAG_NOSIGFD> |
375 | =item C<EVFLAG_SIGNALFD> |
376 | |
376 | |
377 | When this flag is specified, then libev will not attempt to use the |
377 | When this flag is specified, then libev will attempt to use the |
378 | I<signalfd> API for it's C<ev_signal> (and C<ev_child>) watchers. This is |
378 | I<signalfd> API for it's C<ev_signal> (and C<ev_child>) watchers. This API |
379 | probably only useful to work around any bugs in libev. Consequently, this |
379 | delivers signals synchronously, which makes it both faster and might make |
380 | flag might go away once the signalfd functionality is considered stable, |
380 | it possible to get the queued signal data. It can also simplify signal |
381 | so it's useful mostly in environment variables and not in program code. |
381 | handling with threads, as long as you properly block signals in your |
|
|
382 | threads that are not interested in handling them. |
|
|
383 | |
|
|
384 | Signalfd will not be used by default as this changes your signal mask, and |
|
|
385 | there are a lot of shoddy libraries and programs (glib's threadpool for |
|
|
386 | example) that can't properly initialise their signal masks. |
382 | |
387 | |
383 | =item C<EVBACKEND_SELECT> (value 1, portable select backend) |
388 | =item C<EVBACKEND_SELECT> (value 1, portable select backend) |
384 | |
389 | |
385 | This is your standard select(2) backend. Not I<completely> standard, as |
390 | This is your standard select(2) backend. Not I<completely> standard, as |
386 | libev tries to roll its own fd_set with no limits on the number of fds, |
391 | libev tries to roll its own fd_set with no limits on the number of fds, |
… | |
… | |
1862 | Returns the remaining time until a timer fires. If the timer is active, |
1867 | Returns the remaining time until a timer fires. If the timer is active, |
1863 | then this time is relative to the current event loop time, otherwise it's |
1868 | then this time is relative to the current event loop time, otherwise it's |
1864 | the timeout value currently configured. |
1869 | the timeout value currently configured. |
1865 | |
1870 | |
1866 | That is, after an C<ev_timer_set (w, 5, 7)>, C<ev_timer_remaining> returns |
1871 | That is, after an C<ev_timer_set (w, 5, 7)>, C<ev_timer_remaining> returns |
1867 | C<5>. When the timer is started and one second passes, C<ev_timer_remain> |
1872 | C<5>. When the timer is started and one second passes, C<ev_timer_remaining> |
1868 | will return C<4>. When the timer expires and is restarted, it will return |
1873 | will return C<4>. When the timer expires and is restarted, it will return |
1869 | roughly C<7> (likely slightly less as callback invocation takes some time, |
1874 | roughly C<7> (likely slightly less as callback invocation takes some time, |
1870 | too), and so on. |
1875 | too), and so on. |
1871 | |
1876 | |
1872 | =item ev_tstamp repeat [read-write] |
1877 | =item ev_tstamp repeat [read-write] |
… | |
… | |
2132 | C<SA_RESTART> (or equivalent) behaviour enabled, so system calls should |
2137 | C<SA_RESTART> (or equivalent) behaviour enabled, so system calls should |
2133 | not be unduly interrupted. If you have a problem with system calls getting |
2138 | not be unduly interrupted. If you have a problem with system calls getting |
2134 | interrupted by signals you can block all signals in an C<ev_check> watcher |
2139 | interrupted by signals you can block all signals in an C<ev_check> watcher |
2135 | and unblock them in an C<ev_prepare> watcher. |
2140 | and unblock them in an C<ev_prepare> watcher. |
2136 | |
2141 | |
2137 | =head3 The special problem of inheritance over execve |
2142 | =head3 The special problem of inheritance over fork/execve/pthread_create |
2138 | |
2143 | |
2139 | Both the signal mask (C<sigprocmask>) and the signal disposition |
2144 | Both the signal mask (C<sigprocmask>) and the signal disposition |
2140 | (C<sigaction>) are unspecified after starting a signal watcher (and after |
2145 | (C<sigaction>) are unspecified after starting a signal watcher (and after |
2141 | stopping it again), that is, libev might or might not block the signal, |
2146 | stopping it again), that is, libev might or might not block the signal, |
2142 | and might or might not set or restore the installed signal handler. |
2147 | and might or might not set or restore the installed signal handler. |
… | |
… | |
2152 | |
2157 | |
2153 | The simplest way to ensure that the signal mask is reset in the child is |
2158 | The simplest way to ensure that the signal mask is reset in the child is |
2154 | to install a fork handler with C<pthread_atfork> that resets it. That will |
2159 | to install a fork handler with C<pthread_atfork> that resets it. That will |
2155 | catch fork calls done by libraries (such as the libc) as well. |
2160 | catch fork calls done by libraries (such as the libc) as well. |
2156 | |
2161 | |
2157 | In current versions of libev, you can also ensure that the signal mask is |
2162 | In current versions of libev, the signal will not be blocked indefinitely |
2158 | not blocking any signals (except temporarily, so thread users watch out) |
2163 | unless you use the C<signalfd> API (C<EV_SIGNALFD>). While this reduces |
2159 | by specifying the C<EVFLAG_NOSIGFD> when creating the event loop. This |
2164 | the window of opportunity for problems, it will not go away, as libev |
2160 | is not guaranteed for future versions, however. |
2165 | I<has> to modify the signal mask, at least temporarily. |
|
|
2166 | |
|
|
2167 | So I can't stress this enough: I<If you do not reset your signal mask when |
|
|
2168 | you expect it to be empty, you have a race condition in your code>. This |
|
|
2169 | is not a libev-specific thing, this is true for most event libraries. |
2161 | |
2170 | |
2162 | =head3 Watcher-Specific Functions and Data Members |
2171 | =head3 Watcher-Specific Functions and Data Members |
2163 | |
2172 | |
2164 | =over 4 |
2173 | =over 4 |
2165 | |
2174 | |
… | |
… | |
3442 | Erkki Seppala has written Ocaml bindings for libev, to be found at |
3451 | Erkki Seppala has written Ocaml bindings for libev, to be found at |
3443 | L<http://modeemi.cs.tut.fi/~flux/software/ocaml-ev/>. |
3452 | L<http://modeemi.cs.tut.fi/~flux/software/ocaml-ev/>. |
3444 | |
3453 | |
3445 | =item Lua |
3454 | =item Lua |
3446 | |
3455 | |
3447 | Brian Maher has written a partial interface to libev |
3456 | Brian Maher has written a partial interface to libev for lua (at the |
3448 | for lua (only C<ev_io> and C<ev_timer>), to be found at |
3457 | time of this writing, only C<ev_io> and C<ev_timer>), to be found at |
3449 | L<http://github.com/brimworks/lua-ev>. |
3458 | L<http://github.com/brimworks/lua-ev>. |
3450 | |
3459 | |
3451 | =back |
3460 | =back |
3452 | |
3461 | |
3453 | |
3462 | |