EV

 view release on metacpan or  search on metacpan

Changes  view on Meta::CPAN

          the latter of which should disable io_uring compilation
          on old systems.

4.28 Tue Nov 19 13:55:39 CET 2019
	- (libev) fix ev_port backend, thanks to David H. Gutteridge for
        - (libev) many bugfixes in linuxaio backend.
        - (libev) experimental io uring interface.
          reminding me to actually release the fix.
	- try to name ev.h more explicitly, to hopefully improve portability.
        - opportunistically round up wait times for poll and epoll backend,
          to avoid unnecessary loop iterations.
        - add build dependency on ev_linuxaio.c.
        - quickly (re)-ported to minix 3.3 before minix crashed again.

4.27 Thu Jun 27 09:39:58 CEST 2019
	- (libev) completely rewritten linuxaio backend, maybe
          usable as a general-use backend.
	- (libev) use more aggressive assertions to catch
          more usage errors.
	- allow users to re-enable assert() in case it is disabled
          by perl (which is typically the case).

libev/ev.h  view on Meta::CPAN

/*
 * convenience function, wait for a single event, without registering an event watcher
 * if timeout is < 0, do wait indefinitely
 */
EV_API_DECL void ev_once (EV_P_ int fd, int events, ev_tstamp timeout, void (*cb)(int revents, void *arg), void *arg) EV_NOEXCEPT;

EV_API_DECL void ev_invoke_pending (EV_P); /* invoke all pending watchers */

# if EV_FEATURE_API
EV_API_DECL unsigned int ev_iteration (EV_P) EV_NOEXCEPT; /* number of loop iterations */
EV_API_DECL unsigned int ev_depth     (EV_P) EV_NOEXCEPT; /* #ev_loop enters - #ev_loop leaves */
EV_API_DECL void         ev_verify    (EV_P) EV_NOEXCEPT; /* abort if loop data corrupted */

EV_API_DECL void ev_set_io_collect_interval (EV_P_ ev_tstamp interval) EV_NOEXCEPT; /* sleep at least this time, default 0 */
EV_API_DECL void ev_set_timeout_collect_interval (EV_P_ ev_tstamp interval) EV_NOEXCEPT; /* sleep at least this time, default 0 */

/* advanced stuff for threading etc. support, see docs */
EV_API_DECL void ev_set_userdata (EV_P_ void *data) EV_NOEXCEPT;
EV_API_DECL void *ev_userdata (EV_P) EV_NOEXCEPT;
typedef void (*ev_loop_callback)(EV_P);

libev/ev.pod  view on Meta::CPAN

cannot be done in a threadsafe way, but usually it works if no other
thread modifies them).

=item C<EVFLAG_FORKCHECK>

Instead of calling C<ev_loop_fork> manually after a fork, you can also
make libev check for a fork in each iteration by enabling this flag.

This works by calling C<getpid ()> on every iteration of the loop,
and thus this might slow down your event loop if you do a lot of loop
iterations and little real work, but is usually not noticeable (on my
GNU/Linux system for example, C<getpid> is actually a simple 5-insn
sequence without a system call and thus I<very> fast, but my GNU/Linux
system also has C<pthread_atfork> which is even faster). (Update: glibc
versions 2.25 apparently removed the C<getpid> optimisation again).

The big advantage of this flag is that you can forget about fork (and
forget about forgetting to tell libev about forking, although you still
have to ignore C<SIGPIPE>) when you use this flag.

This flag setting cannot be overridden or specified in the C<LIBEV_FLAGS>

libev/ev.pod  view on Meta::CPAN

For few fds, this backend is a bit little slower than poll and select, but
it scales phenomenally better. While poll and select usually scale like
O(total_fds) where total_fds is the total number of fds (or the highest
fd), epoll scales either O(1) or O(active_fds).

The epoll mechanism deserves honorable mention as the most misdesigned
of the more advanced event mechanisms: mere annoyances include silently
dropping file descriptors, requiring a system call per change per file
descriptor (and unnecessary guessing of parameters), problems with dup,
returning before the timeout value, resulting in additional iterations
(and only giving 5ms accuracy while select on the same platform gives
0.1ms) and so on. The biggest issue is fork races, however - if a program
forks then I<both> parent and child process have to recreate the epoll
set, which can take considerable time (one syscall per file descriptor)
and is of course hard to detect.

Epoll is also notoriously buggy - embedding epoll fds I<should> work,
but of course I<doesn't>, and epoll just loves to report events for
totally I<different> file descriptors (even already closed ones, so
one cannot even remove them from the set) than registered in the set

libev/ev.pod  view on Meta::CPAN

C<ev_loop_new>, but it can also be used on the default loop returned by
C<ev_default_loop>, in which case it is not thread-safe.

Note that it is not advisable to call this function on the default loop
except in the rare occasion where you really need to free its resources.
If you need dynamically allocated loops it is better to use C<ev_loop_new>
and C<ev_loop_destroy>.

=item ev_loop_fork (loop)

This function sets a flag that causes subsequent C<ev_run> iterations
to reinitialise the kernel state for backends that have one. Despite
the name, you can call it anytime you are allowed to start or stop
watchers (except inside an C<ev_prepare> callback), but it makes most
sense after forking, in the child process. You I<must> call it (or use
C<EVFLAG_FORKCHECK>) in the child before resuming or calling C<ev_run>.

In addition, if you want to reuse a loop (via this function or
C<EVFLAG_FORKCHECK>), you I<also> have to ignore C<SIGPIPE>.

Again, you I<have> to call it on I<any> loop that you want to re-use after

libev/ev.pod  view on Meta::CPAN

=item int ev_is_default_loop (loop)

Returns true when the given loop is, in fact, the default loop, and false
otherwise.

=item unsigned int ev_iteration (loop)

Returns the current iteration count for the event loop, which is identical
to the number of times libev did poll for new events. It starts at C<0>
and happily wraps around with enough iterations.

This value can sometimes be useful as a generation counter of sorts (it
"ticks" the number of loop iterations), as it roughly corresponds with
C<ev_prepare> and C<ev_check> calls - and is incremented between the
prepare and check phases.

=item unsigned int ev_depth (loop)

Returns the number of times C<ev_run> was entered minus the number of
times C<ev_run> was exited normally, in other words, the recursion depth.

Outside C<ev_run>, this number is zero. In a callback, this number is
C<1>, unless C<ev_run> was invoked recursively (or from another thread),

libev/ev.pod  view on Meta::CPAN

=item ev_set_timeout_collect_interval (loop, ev_tstamp interval)

These advanced functions influence the time that libev will spend waiting
for events. Both time intervals are by default C<0>, meaning that libev
will try to invoke timer/periodic callbacks and I/O callbacks with minimum
latency.

Setting these to a higher value (the C<interval> I<must> be >= C<0>)
allows libev to delay invocation of I/O and timer/periodic callbacks
to increase efficiency of loop iterations (or to increase power-saving
opportunities).

The idea is that sometimes your program runs just fast enough to handle
one (or very few) event(s) per loop iteration. While this makes the
program responsive, it also wastes a lot of CPU time to poll for new
events, especially with backends like C<select ()> which have a high
overhead for the actual polling but can deliver many events at once.

By setting a higher I<io collect interval> you allow libev to spend more
time collecting I/O events, so you can handle more events per iteration,
at the cost of increasing latency. Timeouts (both C<ev_periodic> and
C<ev_timer>) will not be affected. Setting this to a non-null value will
introduce an additional C<ev_sleep ()> call into most loop iterations. The
sleep time ensures that libev will not poll for I/O events more often then
once per this interval, on average (as long as the host time resolution is
good enough).

Likewise, by setting a higher I<timeout collect interval> you allow libev
to spend more time collecting timeouts, at the expense of increased
latency/jitter/inexactness (the watcher callback will be called
later). C<ev_io> watchers will not be affected. Setting this to a non-null
value will not introduce any overhead in libev.

libev/ev.pod  view on Meta::CPAN

as this approaches the timing granularity of most systems. Note that if
you do transactions with the outside world and you can't increase the
parallelity, then this setting will limit your transaction rate (if you
need to poll once per transaction and the I/O collect interval is 0.01,
then you can't do more than 100 transactions per second).

Setting the I<timeout collect interval> can improve the opportunity for
saving power, as the program will "bundle" timer callback invocations that
are "near" in time together, by delaying some, thus reducing the number of
times the process sleeps and wakes up again. Another useful technique to
reduce iterations/wake-ups is to use C<ev_periodic> watchers and make sure
they fire on, say, one-second boundaries only.

Example: we only need 0.1s timeout granularity, and we wish not to poll
more often than 100 times per second:

   ev_set_timeout_collect_interval (EV_DEFAULT_UC_ 0.1);
   ev_set_io_collect_interval (EV_DEFAULT_UC_ 0.01);

=item ev_invoke_pending (loop)

libev/ev.pod  view on Meta::CPAN

=head2 C<ev_child> - watch out for process status changes

Child watchers trigger when your process receives a SIGCHLD in response to
some child status changes (most typically when a child of yours dies or
exits). It is permissible to install a child watcher I<after> the child
has been forked (which implies it might have already exited), as long
as the event loop isn't entered (or is continued from a watcher), i.e.,
forking and then immediately registering a watcher for the child is fine,
but forking and registering a watcher a few event loop iterations later or
in the next callback invocation is not.

Only the default event loop is capable of handling signals, and therefore
you can only register child watchers in the default event loop.

Due to some design glitches inside libev, child watchers will always be
handled at maximum priority (their priority is set to C<EV_MAXPRI> by
libev)

=head3 Process Interaction

libev/ev_iouring.c  view on Meta::CPAN

      iouring_sqe_submit (EV_A_ sqe);
    }
}

inline_size
void
iouring_tfd_update (EV_P_ ev_tstamp timeout)
{
  ev_tstamp tfd_to = mn_now + timeout;

  /* we assume there will be many iterations per timer change, so
   * we only re-set the timerfd when we have to because its expiry
   * is too late.
   */
  if (ecb_expect_false (tfd_to < iouring_tfd_to))
    {
       struct itimerspec its;

       iouring_tfd_to = tfd_to;
       EV_TS_SET (its.it_interval, 0.);
       EV_TS_SET (its.it_value, tfd_to);

libev/ev_vars.h  view on Meta::CPAN

#endif

#if EV_USE_TIMERFD || EV_GENWRAP
VARx(int, timerfd) /* timerfd for time jump detection */
VARx(ev_io, timerfd_w)
#endif

VARx(unsigned int, origflags) /* original loop flags */

#if EV_FEATURE_API || EV_GENWRAP
VARx(unsigned int, loop_count) /* total number of loop iterations/blocks */
VARx(unsigned int, loop_depth) /* #ev_run enters - #ev_run leaves */

VARx(void *, userdata)
/* C++ doesn't support the ev_loop_callback typedef here. stinks. */
VAR (release_cb, void (*release_cb)(EV_P) EV_NOEXCEPT)
VAR (acquire_cb, void (*acquire_cb)(EV_P) EV_NOEXCEPT)
VAR (invoke_cb , ev_loop_callback invoke_cb)
#endif

#undef VARx