Lines Matching refs:at
130 more info about various configuration options please have a look at
249 the current system, you would need to look at C<ev_embeddable_backends ()
262 Since some systems (at least OpenBSD and Darwin) fail to implement
315 safe to call this function at any time, from any context, including signal
400 or setgid) then libev will I<not> look at the environment variable
474 a look at C<ev_set_io_collect_interval ()> to increase the amount of
540 i.e. keep at least one watcher active per fd at all times. Stopping and
558 Kqueue deserves special mention, as at the time of this writing, it
636 at all.
640 Not a backend at all, but a mask to select all backend bits from a
705 call it at all (in fact, C<epoll> is so badly broken that it makes a
732 to the number of times libev did poll for new events. It starts at C<0>
841 will block your process until at least one new event arrives (which could
867 - Calculate for how long to sleep or block, if at all
869 any active watchers at all will result in not sleeping).
964 overhead for the actual polling but can deliver many events at once.
968 at the cost of increasing latency. Timeouts (both C<ev_periodic> and
976 to spend more time collecting timeouts, at the expense of increased
1135 *) >>), and you can stop watching for events at any time by calling the
1147 (you can receive multiple events at the same time). The possible bit masks
1256 You can reinitialise a watcher at any time as long as it has been stopped
1271 call C<ev_init> at least once before you call this macro, but you can
1333 Change the callback. You can change the callback at virtually any time
1347 you need to look at C<ev_idle> watchers, which provide this functionality.
1413 use in an event loop. It can be moved around, freed, reused etc. at
1436 but it is still property of the event loop at this time, so cannot be
1520 Here is an example of an I/O watcher that should run at a strictly lower
1570 while the watcher is active, you can look at the member and expect some
1575 sensible or take immediate effect (or do anything at all), but libev will
1583 would not block the process and writing would at least be able to write
1679 Some backends (epoll, kqueue) do not support C<fork ()> at all or exhibit
1708 typically causing the program to loop at 100% CPU usage.
1722 messages, and continue as usual, which at least gives the user an idea of
1792 passed (not I<at>, so on systems with very low-resolution clocks this
1840 of C<60> and then call C<ev_timer_again> at start and each time you
1916 Otherwise, we now the earliest time at which the timeout would trigger,
1921 again at the earliest time it could time out. Rinse. Repeat.
1937 C<last_activity>, no libev calls at all:
1960 at the I<end> of the list.
1962 Then use an C<ev_timer> to fire when the timeout at the I<beginning> of
1970 starting, stopping and updating the timers, at the expense of a major
2006 yourself). If you schedule a one-second timer at the time 500.9, then the
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 >=
2018 the callback at system time 502, or 1.1s after the timer was started.
2028 at least one system call): EV therefore updates its idea of the current
2060 C<ev_time ()> and C<ev_now ()>, at least if you want better precision than
2106 and C<ev_resume> in code that handles C<SIGTSTP>, to at least get
2124 The timer itself will do a best-effort at avoiding drift, that is, if
2126 trigger at exactly 10 second intervals. If, however, your program cannot
2203 // reset the timeout to start ticking again at 10 seconds
2255 time jump occurs, that is, if it is to be run at January 1st 2011 then it
2261 In this mode the watcher will always be scheduled to time out at the next
2278 C<ev_periodic> will try to run the callback in this mode at the next possible
2284 at most a similar magnitude as the current time (say, within a factor of
2320 might be called at other times, too.
2421 C<SIGINT> in both the default loop and another loop at the same time. At
2458 I<has> to modify the signal mask, at least temporarily.
2525 handled at maximum priority (their priority is set to C<EV_MAXPRI> by
2565 at the C<rstatus> member of the C<ev_child> watcher structure to see
2628 C<st_nlink> field being zero (which is otherwise always forced to be at
2673 When C<inotify (7)> support has been compiled into libev and present at
2689 descriptor open on the object at all times, and detecting renames, unlinks
2751 relative to the attributes at the time the watcher was started (or the
2865 As long as there is at least one active idle watcher, libev will never
2867 For this to work, the idle watcher doesn't need to be invoked at all - the
3146 C<kevent>, but at least you can use both mechanisms for what they are
3387 queue. But at least I can tell you how to implement locking around your
3486 compressed into a single callback invocation (another way to look at
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
3542 a timeout and an io event at the same time - you probably should give io
3579 or modify at any time: libev will completely ignore it. This can be used
4005 that the watcher is associated with (or no additional members at all if
4071 callback (i.e. it is visible to it at the place of the C<set> call and
4138 must be called at least once. Unlike the C counterpart, an active watcher
4218 It can be found and installed via CPAN, its homepage is at
4223 Python bindings can be found at L<http://code.google.com/p/pyev/>. It
4230 more on top of it. It can be found via gem servers. Its homepage is at
4238 A haskell binding to libev is available at
4244 be found at L<http://www.llucax.com.ar/proj/ev.d/index.html>.
4248 Erkki Seppala has written Ocaml bindings for libev, to be found at
4253 Brian Maher has written a partial interface to libev for lua (at the
4254 time of this writing, only C<ev_io> and C<ev_timer>), to be found at
4378 compiler (at least, that's a stated goal, and breakage will be treated
4482 monotonic clock option at both compile time and runtime. Otherwise no
4492 real-time clock option at compile time (and assume its availability
4493 at runtime if successful). Otherwise no use of the real-time clock
4519 available and will probe for kernel support at runtime. This will improve
4527 C<select>(2) backend. No attempt at auto-detection will be done: if no
4589 C<epoll>(7) backend. Its availability will be detected at runtime,
4597 C<kqueue>(2) backend. Its actual availability will be detected at runtime,
4609 10 port style backend. Its availability will be detected at runtime,
4621 be detected at runtime. If undefined, it will be enabled if the headers
4713 If you need to shave off some kilobytes of code at the expense of some
4753 and can additionally have an effect on the size of data structures at
4779 This enables all backends - without this feature, you need to enable at
4797 I/O watcher then might come out at only 5Kb.
4815 If this is set to C<1> at compiletime, then libev will avoid using stdio
4861 timer and periodics heaps, libev can cache the timestamp (I<at>) within
4939 verbatim, you can have a look at the EV perl module
4982 only one thread ever is inside a call at any point in time, e.g. by using
5270 can only wait for C<64> things at the same time internally; Microsoft
5334 systems (Microsoft...) this might be unexpectedly low, but is still at
5341 have at least 51 bits of mantissa (and 9 bits of exponent), which is
5342 good enough for at least into the year 4000 with millisecond accuracy
5346 With IEEE 754 doubles, you get microsecond accuracy until at least the
5383 These just add the watcher into an array or at the head of a list.
5396 By virtue of using a binary or 4-heap, the next timer is always found at a