… | |
… | |
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, |
… | |
… | |
792 | |
797 | |
793 | Ref/unref can be used to add or remove a reference count on the event |
798 | Ref/unref can be used to add or remove a reference count on the event |
794 | loop: Every watcher keeps one reference, and as long as the reference |
799 | loop: Every watcher keeps one reference, and as long as the reference |
795 | count is nonzero, C<ev_loop> will not return on its own. |
800 | count is nonzero, C<ev_loop> will not return on its own. |
796 | |
801 | |
797 | If you have a watcher you never unregister that should not keep C<ev_loop> |
802 | This is useful when you have a watcher that you never intend to |
798 | from returning, call ev_unref() after starting, and ev_ref() before |
803 | unregister, but that nevertheless should not keep C<ev_loop> from |
|
|
804 | returning. In such a case, call C<ev_unref> after starting, and C<ev_ref> |
799 | stopping it. |
805 | before stopping it. |
800 | |
806 | |
801 | As an example, libev itself uses this for its internal signal pipe: It |
807 | As an example, libev itself uses this for its internal signal pipe: It |
802 | is not visible to the libev user and should not keep C<ev_loop> from |
808 | is not visible to the libev user and should not keep C<ev_loop> from |
803 | exiting if no event watchers registered by it are active. It is also an |
809 | exiting if no event watchers registered by it are active. It is also an |
804 | excellent way to do this for generic recurring timers or from within |
810 | excellent way to do this for generic recurring timers or from within |
… | |
… | |
1854 | C<repeat> value), or reset the running timer to the C<repeat> value. |
1860 | C<repeat> value), or reset the running timer to the C<repeat> value. |
1855 | |
1861 | |
1856 | This sounds a bit complicated, see L<Be smart about timeouts>, above, for a |
1862 | This sounds a bit complicated, see L<Be smart about timeouts>, above, for a |
1857 | usage example. |
1863 | usage example. |
1858 | |
1864 | |
1859 | =item ev_timer_remaining (loop, ev_timer *) |
1865 | =item ev_tstamp ev_timer_remaining (loop, ev_timer *) |
1860 | |
1866 | |
1861 | 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, |
1862 | 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 |
1863 | the timeout value currently configured. |
1869 | the timeout value currently configured. |
1864 | |
1870 | |
… | |
… | |
2131 | C<SA_RESTART> (or equivalent) behaviour enabled, so system calls should |
2137 | C<SA_RESTART> (or equivalent) behaviour enabled, so system calls should |
2132 | 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 |
2133 | 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 |
2134 | and unblock them in an C<ev_prepare> watcher. |
2140 | and unblock them in an C<ev_prepare> watcher. |
2135 | |
2141 | |
2136 | =head3 The special problem of inheritance over execve |
2142 | =head3 The special problem of inheritance over fork/execve/pthread_create |
2137 | |
2143 | |
2138 | Both the signal mask (C<sigprocmask>) and the signal disposition |
2144 | Both the signal mask (C<sigprocmask>) and the signal disposition |
2139 | (C<sigaction>) are unspecified after starting a signal watcher (and after |
2145 | (C<sigaction>) are unspecified after starting a signal watcher (and after |
2140 | 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, |
2141 | 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. |
… | |
… | |
2151 | |
2157 | |
2152 | 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 |
2153 | 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 |
2154 | 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. |
2155 | |
2161 | |
2156 | 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 |
2157 | 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 |
2158 | 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 |
2159 | 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. |
2160 | |
2170 | |
2161 | =head3 Watcher-Specific Functions and Data Members |
2171 | =head3 Watcher-Specific Functions and Data Members |
2162 | |
2172 | |
2163 | =over 4 |
2173 | =over 4 |
2164 | |
2174 | |