Lines Matching refs:event
5 libev - a high performance full-featured event loop written in C
49 // use the default event loop unless you have special needs
79 on event-based programming, nor will it introduce event-based programming
82 Familiarity with event based programming techniques in general is assumed
95 Libev is an event loop: you register interest in certain events (such as a
97 these event sources and provide your program with events.
100 (or thread) by executing the I<event loop> handler, and will then
103 You register interest in certain events by registering so-called I<event
105 details of the event, and then hand it over to libev by I<starting> the
111 BSD-specific C<kqueue> and the Solaris-specific event port mechanisms
117 change events (C<ev_child>), and event watchers dealing with the event
129 configuration will be described, which supports multiple event loops. For
132 for multiple event loops, then all functions taking an initial argument of
246 Returns the set of backends that are embeddable in other event loops. This
329 An event loop is described by a C<struct ev_loop *> (the C<struct> is
334 supports child process events, and dynamically created event loops which
341 This returns the "default" event loop object, which is what you should
342 normally use when you just need "the event loop". Event loop objects and
352 If you don't know what event loop to use, use the one returned from this
378 This will create and initialise a new event loop object. If the loop
414 and thus this might slow down your event loop if you do a lot of loop
504 of the more advanced event mechanisms: mere annoyances include silently
527 Epoll is truly the train wreck among event poll mechanisms, a frankenpoll,
550 While nominally embeddable in other event loops, this feature is broken in
576 two event changes per incident. Support for C<fork ()> is very bad (you
582 While nominally embeddable in other event loops, this doesn't work
585 (for which it usually works), by embedding it into another event loop
602 This uses the Solaris 10 event port mechanism. As with everything on Solaris,
616 even sun itself gets it wrong in their code examples: The event polling
620 absolutely have to know whether an event occurred or not because you have
651 Example: Try to create a event loop that uses epoll and nothing else.
664 Destroys an event loop object (frees all memory and kernel state
665 etc.). None of the active event watchers will be stopped in the normal
703 process if and only if you want to use the event loop in the child. If
731 Returns the current iteration count for the event loop, which is identical
756 Returns one of the C<EVBACKEND_*> flags indicating the event backend in
761 Returns the current "event loop time", which is the time the event loop
765 event occurring (or more correctly, libev finding out about it).
773 This function is rarely useful, but when some event callback runs for a
774 very long time without entering the event loop, updating libev's idea of
783 These two functions suspend and resume an event loop, for use when the
803 event loop time (see C<ev_now_update>).
807 Finally, this is it, the event handler. This function usually is called
811 is why event loops are called I<loops>.
814 until either no event watchers are active anymore or C<ev_break> was
841 will block your process until at least one new event arrives (which could
842 be an event internal to libev itself, so there is no guarantee that a
846 This is useful if you are waiting for some external event in conjunction
866 - Update the "event loop time" (ev_now ()).
874 - Update the "event loop time" (ev_now ()), and do time jump adjustments.
893 ... queue jobs here, make sure they register event watchers as long
914 Ref/unref can be used to add or remove a reference count on the event
925 exiting if no event watchers registered by it are active. It is also an
961 one (or very few) event(s) per loop iteration. While this makes the
1011 event handling to another thread (you still have to make sure only one
1036 to wait for it to return. One way around this is to wake up the event
1047 While event loop modifications are allowed between invocations of
1049 modifications done will affect the event loop, i.e. adding watchers will
1095 your interest in some event. To make a concrete example, imagine you want
1124 invoked each time the event occurs (or, in the case of I/O watchers, each
1125 time the event loop detects that the file descriptor given is readable
1142 Each and every callback receives the event loop pointer as first, the
1146 The received events usually include a single bit per event type received
1191 watchers invoked before the event loop sleeps or polls for new events, and
1193 or lower priority within an event loop iteration.
1202 The embedded event loop specified in the C<ev_embed> watcher needs attention.
1206 The event loop has been resumed in the child process after fork (see
1211 The event loop is about to be destroyed (see C<ev_cleanup>).
1380 Feeds the given event set into the event loop, as if the specified event
1382 initialised but not necessarily started event watcher). Obviously you must
1386 C<ev_clear_pending> will clear the pending event, even if the watcher was
1408 Before a watcher can be registered with the event loop it has to be
1413 use in an event loop. It can be moved around, freed, reused etc. at
1420 property of the event loop, and is actively waiting for events. While in
1427 If a watcher is active and libev determines that an event it is interested
1436 but it is still property of the event loop at this time, so cannot be
1440 It is also possible to feed an event on a watcher that is not active (e.g.
1461 Many event loops support I<watcher priorities>, which are usually small
1462 integers that influence the ordering of event callback invocation
1470 by event loops:
1477 callback invocation within a single event loop iteration: Higher priority
1485 watchers is not well supported by most kernel interfaces, and most event
1506 For example, to emulate how many other event libraries handle priorities,
1510 continuously poll and process kernel event data for the watcher, but when
1517 idle watcher, so the kernel will not have to process the event in case
1525 ev_io io; // actual event watcher
1530 // stop the I/O watcher, we received the event, but
1534 // start the idle watcher to handle the actual event.
1547 // we have handled the event
1582 in each iteration of the event loop, or, more precisely, when reading
1586 the watcher if you don't want to act on the event and neither want to
1589 In general you can register as many read and/or write event watchers per
1718 event-based way to handle this situation, so it's the best one can do.
1782 Timer watchers are simple relative timers that generate an event after a
1785 The timers are based on real time, that is, if you register an event that
1999 A less obvious failure mode is calling your callback too early: many event
2007 event loop will schedule your timeout to elapse at a system time of 500
2010 If an event library looks at the timeout 0.1s later, it will see "501 >=
2035 of the event triggering whatever timeout you are modifying/starting. If
2036 you suspect event processing to be delayed and you I<need> to base the
2042 If the event loop is suspended for a long time, you can also force an
2044 ()>, although that will push the event time of all outstanding events
2128 do stuff) the timer will not fire more than once per event loop iteration.
2157 then this time is relative to the current event loop time, otherwise it's
2223 year, then it will take a year or more to trigger the event (unlike an
2228 timers, such as triggering an event on each "midnight, local time", or
2253 In this configuration the watcher triggers an event after the wall clock
2301 or make ANY other event loop modifications whatsoever, unless explicitly
2306 only event loop modification you are allowed to do).
2408 Signal watchers will trigger an event when the process receives a specific
2411 normal event processing, like any other event.
2416 synchronously wake up an event loop.
2462 is not a libev-specific thing, this is true for most event libraries.
2516 as the event loop isn't entered (or is continued from a watcher), i.e.,
2518 but forking and registering a watcher a few event loop iterations later or
2521 Only the default event loop is capable of handling signals, and therefore
2522 you can only register child watchers in the default event loop.
2530 Libev grabs C<SIGCHLD> as soon as the default event loop is
2534 synchronously as part of the event loop processing. Libev always reaps all
2544 event-based approach to child reaping and thus use libev's support for
2750 The callback will receive an C<EV_STAT> event when a change was detected,
2851 are pending), the idle watchers are being called once per event loop
2861 event loop has handled all outstanding events.
2871 to do something on each event loop iteration - for example to balance load
2912 =head2 C<ev_prepare> and C<ev_check> - customise your event loop!
2919 current event loop) or C<ev_loop_fork> from either C<ev_prepare> or
2926 Their main purpose is to integrate other event mechanisms into libev and
2947 with priority higher than or equal to the event loop and one coroutine
2948 of lower priority, but only once, using idle watchers to keep the event
2960 C<ev_check> watchers are often used to embed other (non-libev) event
2961 loops those other event loops might be in an unusable state until their
2968 useful because they are called once per event loop iteration. For
2971 is more work to do, you wait for the next event loop iteration, so other
2975 next event loop iteration. However, that isn't as soon as possible -
2980 C<ev_check> watcher. The C<ev_idle> watcher makes sure the event loop
3001 There are a number of principal ways to embed other event loops or modules
3006 Glib event loop).
3072 Method 3: If the module to be embedded supports explicit event
3102 libglib event loop.
3132 This is a rather advanced watcher type that lets you embed one event loop
3209 The embedded event loop.
3215 Example: Try to get an embeddable event loop and embed it into the default
3216 event loop. If that is not possible, use the default loop. The default
3242 kqueue implementation). Store the kqueue/socket-only event loop in
3262 =head2 C<ev_fork> - the audacity to resume the event loop after a fork
3266 C<ev_loop_fork>). The invocation is done before the event loop blocks next
3278 This changes when the application actually wants to do event handling
3292 simply create a new event loop, which of course will be "empty", and
3295 disadvantage of having to use multiple event loops (which do not support
3321 Cleanup watchers are called just before the event loop is being destroyed
3324 While there is no guarantee that the event loop gets destroyed, cleanup
3330 all other watchers, they do not keep a reference to the event loop (which
3359 =head2 C<ev_async> - how to wake up an event loop
3362 asynchronous sources such as signal handlers (as opposed to multiple event
3365 Sometimes, however, you need to wake up an event loop you do not control,
3478 an C<EV_ASYNC> event on the watcher into the event loop, and instantly
3488 C<ev_async_send>, reset when the event loop detects that).
3490 This call incurs the overhead of at most one extra system call per event
3491 loop iteration, if the event loop is blocked, and no syscall at all if
3492 the event loop (or your program) is processing events. That means that
3500 watcher but the event has not yet been processed (or even noted) by the
3501 event loop.
3510 is a time window between the event loop checking and resetting the async
3525 callback on whichever event happens first and automatically stops both
3526 watchers. This is useful if you want to wait for a single event on an fd
3539 passed an C<revents> set like normal event callbacks (a combination of
3542 a timeout and an io event at the same time - you probably should give io
3559 Feed an event on the given fd, as if a file descriptor backend detected
3564 Feed an event as if the given signal occurred. See also C<ev_feed_signal>,
3613 multiple libev event sources into one "super-watcher":
3646 Often you have structures like this in event-based programs:
3725 Here is a fictitious example of how to run an event loop in a different
3735 event loop thread and an unspecified mechanism to wake up the main thread.
3737 First, you need to associate some data with the event loop:
3767 solely to wake up the event loop so it takes notice of any new watchers
3793 The event loop thread first acquires the mutex, and then jumps straight
3844 event loop, you will now have to lock:
3857 an event loop currently blocking in the kernel will have no knowledge
3859 watchers in the next event loop iteration.
3872 event" primitive by changing C<EV_CB_DECLARE> and C<EV_CB_INVOKE> (note
3882 A coroutine might now wait for an event with a function called
3898 You can do similar tricks if you have, say, threads with an event queue -
3932 =item * Use it by including <event.h>, as usual.
4004 classes add (compared to plain C-style watchers) is the event loop pointer
4048 The constructor (optionally) takes an event loop to associate the watcher
4148 constructor already stores the event loop.
4215 C<Net::SNMP> (C<Net::SNMP::EV>) and the C<libglib> event core (C<Glib::EV>
4259 Node.js (L<http://nodejs.org>) uses libev as the underlying event library.
4404 #include "event.c"
4408 #include "event.h"
4414 event.h
4415 event.c
4465 F<event.h> that are not directly supported by the libev core alone.
4653 undefined is C<"ev.h"> in F<event.h>, F<ev.c> and F<ev++.h>. This can be
4664 Similarly to C<EV_H>, this macro can be used to override F<event.c>'s idea
4665 of how the F<event.h> header can be found, the default is C<"event.h">.
4676 If undefined or defined to C<1>, then all event-loop-specific functions
4678 additional independent event loops. Otherwise there will be no support
4679 for multiple event loops and there is no first event loop pointer
4721 but multiple event loop support, async and child watchers and the poll
4918 Symbols.event for the libevent emulation
4976 of course): libev guarantees that different event loops share no data
4987 concurrency on the same event loop, namely waking it up "from the
5014 event loop.
5022 watcher callback into the event loop interested in the signal.
5172 The scalable event interface for Solaris is called "event
5177 are multiple ones to apply, and afterwards, event ports actually work
5207 also that glib is the slowest event library known to man).
5379 as only the relative motion in the event queue has to be paid for.
5507 The address of a function that is called when some event has been
5508 detected. Callbacks are being passed the event loop, the watcher that
5509 received the event, and the actual event bitset.
5515 =item event
5517 A change of state of some external event, such as data now being available
5524 =item event library
5526 A software package implementing an event model and loop.
5528 =item event loop
5533 =item event model
5535 The model used to describe how an event loop handles and processes
5540 A watcher is pending as soon as the corresponding event has been
5556 to be started (attached to an event loop) before they can receive events.