Lines Matching refs:events

29      // for one-shot events, one must manually stop the watcher
62 // now wait for events to arrive
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.
101 communicate events via a callback mechanism.
103 You register interest in certain events by registering so-called I<event
112 for file descriptor events (C<ev_io>), the Linux C<inotify> interface
117 change events (C<ev_child>), and event watchers dealing with the event
120 limited support for fork events (C<ev_fork>).
334 supports child process events, and dynamically created event loops which
515 but of course I<doesn't>, and epoll just loves to report events for
520 that against the events to filter out spurious ones, recreating the set
535 file descriptors might not work very well if you register events for both
617 function sometimes returns events to the caller even though an error
732 to the number of times libev did poll for new events. It starts at C<0>
762 received events and started processing them. This timestamp does not
795 will be rescheduled (that is, they will lose any events that would have
809 handling events. It will ask the operating system for any new events, call
813 If the flags argument is specified as C<0>, it will keep handling events
833 A flags value of C<EVRUN_NOWAIT> will look for new events, will handle
834 those events and any already outstanding ones, but will not wait and
835 block your process in case there are no events and will return after one
837 events while doing lengthy calculations, to keep the program responsive.
839 A flags value of C<EVRUN_ONCE> will look for new events (waiting if
872 - Block the process, waiting for any events.
873 - Queue all outstanding I/O (fd) events.
877 - Queue all idle watchers with priority higher than that of pending events.
890 Example: Queue some jobs and then loop until no events are outstanding
901 has processed all outstanding events). The C<how> argument must be either
951 for events. Both time intervals are by default C<0>, meaning that libev
963 events, especially with backends like C<select ()> which have a high
964 overhead for the actual polling but can deliver many events at once.
967 time collecting I/O events, so you can handle more events per iteration,
971 sleep time ensures that libev will not poll for I/O events more often then
1041 suspended waiting for new events, and C<acquire> is called just
1133 To make the watcher actually watch out for events, you have to start it
1135 *) >>), and you can stop watching for events at any time by calling the
1143 registered watcher structure as second, and a bitset of received events as
1146 The received events usually include a single bit per event type received
1147 (you can receive multiple events at the same time). The possible bit masks
1188 gather new events, and all C<ev_check> watchers are queued (not invoked)
1190 for any received events. That means C<ev_prepare> watchers are the last
1191 watchers invoked before the event loop sleeps or polls for new events, and
1234 Libev will usually signal a few "dummy" events together with an error, for
1257 (or never started) and there are no pending events outstanding.
1294 events. If the watcher is already active nothing will happen.
1321 events but its callback has not yet been invoked). As long as a watcher
1346 If you need to suppress invocation when higher priority events are pending
1383 not free the watcher as long as it has pending events.
1420 property of the event loop, and is actively waiting for events. While in
1474 watchers receive events, lower priority watchers are not being invoked.
1479 before polling for new events.
1486 libraries will just poll for the same events again and again as long as
1503 received events, they can be used to implement the "lock-out" model when
1522 other events are pending:
1536 // with the default priority are receiving events.
1585 receiving events as long as the condition persists. Remember you can stop
1587 receive future events.
1635 Some backends (e.g. epoll), cannot register events for file descriptors,
1636 but only events for the underlying file descriptions. That means when you
1638 events for them, only one file descriptor might actually receive events.
1640 There is no workaround possible except not registering events
1741 =item ev_io_init (ev_io *, callback, int fd, int events)
1743 =item ev_io_set (ev_io *, int fd, int events)
1746 receive events for and C<events> is either C<EV_READ>, C<EV_WRITE> or
1747 C<EV_READ | EV_WRITE>, to express the desire to receive the given events.
1753 =item int events [read-only]
1755 The events being watched.
1875 our example, within 60 seconds, there are usually many I/O events with
2029 time only before and after C<ev_run> collects new events, which causes a
2031 lots of events in one iteration.
2044 ()>, although that will push the event time of all outstanding events
2844 Idle watchers trigger events when no other events of the same or higher
2846 as receiving "events").
2852 iteration - until stopped, that is, or your process receives more events
2856 active, the process will not block when waiting for new events.
2861 event loop has handled all outstanding events.
2938 you check for any events that occurred (by checking the pending status
2958 activate ("feed") events into libev. While libev fully supports this, they
2976 without external events, your C<ev_check> watcher will not be invoked.
3039 ((fds [i].events & POLLIN ? EV_READ : 0)
3040 | (fds [i].events & POLLOUT ? EV_WRITE : 0)));
3059 if (revents & EV_READ ) fd->revents |= fd->events & POLLIN;
3060 if (revents & EV_WRITE) fd->revents |= fd->events & POLLOUT;
3133 into another (currently only C<ev_io> events are supported in the embedded
3156 time there might be events pending in the embedded loop. The callback
3485 Note that, as with other watchers in libev, multiple events might get
3492 the event loop (or your program) is processing events. That means that
3522 =item ev_once (loop, int fd, int events, ev_tstamp timeout, callback)
3531 C<events> argument is being ignored. Otherwise, an C<ev_io> watcher for
3532 the given C<fd> and C<events> set will be created and started.
3543 events precedence.
3560 the given events.
5019 An example use would be to communicate signals or other events that only
5422 blocked. Checking for async and signal events involves iterating over all
5519 any other events happening anymore.
5521 In libev, events are represented as single bits (such as C<EV_READ> or
5530 An entity that handles and processes external events and converts them
5536 watchers and events.
5555 A data structure that describes interest in certain events. Watchers need
5556 to be started (attached to an event loop) before they can receive events.