Lines Matching refs:signal

114 inter-thread wakeup (C<ev_async>)/signal handling (C<ev_signal>)) relative
314 This function can be used to "simulate" a signal receive. It is completely
315 safe to call this function at any time, from any context, including signal
318 Its main use is to customise signal handling in your process, especially
364 C<SIGCHLD> signal handler I<after> calling C<ev_default_init>.
439 it possible to get the queued signal data. It can also simplify signal
443 Signalfd will not be used by default as this changes your signal mask, and
445 example) that can't properly initialise their signal masks.
449 When this flag is specified, then libev will avoid to modify the signal
453 This behaviour is useful when you want to do your own signal handling, or
672 Note that certain global state, such as signal state (and installed signal
674 as signal and child watchers) would need to be stopped manually.
923 As an example, libev itself uses this for its internal signal pipe: It
933 Example: Create a signal watcher, but keep it from keeping C<ev_run>
941 Example: For some weird reason, unregister the above signal handler again.
1169 The signal specified in the C<ev_signal> watcher has been received by a thread.
1220 by libev users to signal watchers (e.g. via C<ev_feed_event>).
1234 Libev will usually signal a few "dummy" events together with an error, for
1994 process with a STOP signal for a few hours for example.
2406 =head2 C<ev_signal> - signal me when a signal gets signalled!
2409 signal one or more times. Even though signals are very asynchronous, libev
2415 the signal. You can even use C<ev_async> from a signal handler to
2418 You can configure as many watchers as you like for the same signal, but
2424 Only after the first watcher for a signal is started will libev actually
2425 register something with the kernel. It thus coexists with your own signal
2426 handlers as long as you don't register any with libev for the same signal.
2436 Both the signal mask (C<sigprocmask>) and the signal disposition
2437 (C<sigaction>) are unspecified after starting a signal watcher (and after
2438 stopping it again), that is, libev might or might not block the signal,
2439 and might or might not set or restore the installed signal handler (but
2442 While this does not matter for the signal disposition (libev never
2444 C<execve>), this matters for the signal mask: many programs do not expect
2448 the signal mask to whatever "default" you expect (all clear is a good
2451 The simplest way to ensure that the signal mask is reset in the child is
2455 In current versions of libev, the signal will not be blocked indefinitely
2458 I<has> to modify the signal mask, at least temporarily.
2460 So I can't stress this enough: I<If you do not reset your signal mask when
2464 =head3 The special problem of threads signal handling
2466 POSIX threads has problematic signal handling semantics, specifically,
2470 When you want to use sigwait (or mix libev signal handling with your own
2474 loops. Then designate one thread as "signal receiver thread" which handles
2486 Configures the watcher to trigger on the given signal number (usually one
2491 The signal the watcher watches out for.
3296 signal watchers).
3304 signal watchers.
3362 asynchronous sources such as signal handlers (as opposed to multiple event
3367 watchers do: as long as the C<ev_async> watcher is active, you can signal
3368 it by calling C<ev_async_send>, which is thread- and signal safe.
3373 C<ev_async_send> calls). In fact, you could use signal watchers as a kind
3375 signal, and C<ev_feed_signal> to signal this watcher from another thread,
3376 even without knowing which loop owns the signal.
3392 =item queueing from a signal handler context
3394 To implement race-free queueing, you simply add to the queue in the signal
3395 handler but you block the signal handler in the watcher callback. Here is
3482 signal or similar contexts (see the discussion of C<EV_ATOMIC_T> in the
3564 Feed an event as if the given signal occurred. See also C<ev_feed_signal>,
3810 signal the main thread via some unspecified mechanism (signals? pipe
3829 will grab the lock, call C<ev_invoke_pending> and then signal the loop
3946 base that registered the signal gets the signals.
4035 which is called C<ev::sig> to avoid clashes with the C<signal> macro
4634 different threads (that includes signal handlers), which is a stronger
4641 access is atomic with respect to other threads or signal contexts. No
4643 type that you know is safe for your purposes. It is used both for signal
4644 handler "locking" as well as for signal and thread safety in C<ev_async>
4648 (from F<signal.h>), which is usually good enough on most platforms.
4826 The highest supported signal number, +1 (or, the number of
4831 statically allocates some 12-24 bytes per signal number.
4985 Specifically to support threads (and signal handlers), libev implements
5017 (or from signal contexts...).
5020 work in the default loop by registering the signal watcher with the
5022 watcher callback into the event loop interested in the signal.
5212 Sensible signal handling is officially unsupported by Microsoft - libev
5327 except the initial one, and run the signal handling loop in the initial
5381 =item Starting io/check/prepare/idle/signal/child/fork/async watchers: O(1)
5387 =item Stopping an io/signal/child watcher: O(number_of_watchers_for_this_(fd/signal/pid % EV_PID_HA…
5391 have many watchers waiting for the same fd or signal: one is typical, two
5422 blocked. Checking for async and signal events involves iterating over all
5423 running async watchers or all signal numbers.