Lines Matching refs:or

96 file descriptor being readable or a timeout occurring), and it will manage
99 To do this, it must take more or less complete control over your process
100 (or thread) by executing the I<event loop> handler, and will then
155 set via C<ev_set_syserr_cb>, which is supposed to fix the problem or
166 circumstances, as they indicate either a bug in libev or worse.
186 until either it is interrupted or the given time interval has
215 such as LFS or reentrancy).
260 or take some potentially destructive action.
268 or even to sleep a while and retry until some memory is available.
294 indicating the system call or subsystem causing the problem. If this
297 requested operation, or, if the condition doesn't go away, do bad stuff
316 handlers or random threads.
321 creating any loops), and in one thread, use C<sigwait> or any other
350 one calling C<ev_run> or otherwise qualifies as "the main program".
353 function (or via the C<EV_DEFAULT> macro).
363 C<ev_loop_new> which doesn't do that, or you can simply overwrite the
383 loop in the "main" or "initial" thread.
385 The flags argument can be used to specify special behaviour or specific
386 backends to use, and is usually specified as C<0> (or C<EVFLAG_AUTO>).
399 If this flag bit is or'ed into the flag value (or the program runs setuid
400 or setgid) then libev will I<not> look at the environment variable
404 around bugs, or to make libev threadsafe (accessing environment variables
424 This flag setting cannot be overridden or specified in the C<LIBEV_FLAGS>
453 This behaviour is useful when you want to do your own signal handling, or
500 O(total_fds) where total_fds is the total number of fds (or the highest
501 fd), epoll scales either O(1) or O(active_fds).
528 cobbled together in a hurry, no thought to design or interaction with
546 All this means that, in practice, C<EVBACKEND_SELECT> can be as fast or
565 C<EVBACKEND_KQUEUE>) or libev was compiled on a known-to-be-good (-enough)
568 You still can embed kqueue into a normal poll or select backend and use it
586 (e.g. C<EVBACKEND_SELECT> or C<EVBACKEND_POLL> (but C<poll> is of course
607 descriptors a "slow" C<EVBACKEND_SELECT> or C<EVBACKEND_POLL> backend
618 occurred, but with no indication whether it has done so or not (yes, it's
620 absolutely have to know whether an event occurred or not because you have
635 C<ev_recommended_backends ()> returns, or simply do not specify a backend
646 If one or more of the backend flags are or'ed into the flags value,
668 calling this function, or cope with the fact afterwards (which is usually
669 the easiest thing, you can just ignore the watchers and/or C<free ()> them
689 the name, you can call it anytime you are allowed to start or stop
691 sense after forking, in the child process. You I<must> call it (or use
692 C<EVFLAG_FORKCHECK>) in the child before resuming or calling C<ev_run>.
694 In addition, if you want to reuse a loop (via this function or
704 you just fork+exec or create a new loop in the child, you don't have to
746 C<1>, unless C<ev_run> was invoked recursively (or from another thread),
765 event occurring (or more correctly, libev finding out about it).
814 until either no event watchers are active anymore or C<ev_break> was
818 usually means "all jobs done" or "deadlock"), and true in all other cases
867    - Calculate for how long to sleep or block, if at all
868      (active idle watchers, EVRUN_NOWAIT or not having
882    - If ev_break has been called, or EVRUN_ONCE or EVRUN_NOWAIT
883      were used, or there are no active watchers, goto FINISH, otherwise
896    ... jobs done or somebody called break. yeah!
902 C<EVBREAK_ONE>, which will make the innermost C<ev_run> call return, or
914 Ref/unref can be used to add or remove a reference count on the event
926 excellent way to do this for generic recurring timers or from within
928 before stop> (but only if the watcher wasn't active before, or was active
957 to increase efficiency of loop iterations (or to increase power-saving
961 one (or very few) event(s) per loop iteration. While this makes the
982 interval to a value near C<0.1> or so, which is often enough for
1012 thread executes within C<ev_invoke_pending> or C<ev_run> of course).
1050 have no effect on the set of file descriptors being watched, or the time
1120 or simply C<ev_TYPE>, as typedefs are provided for all watcher structs).
1124 invoked each time the event occurs (or, in the case of I/O watchers, each
1126 and/or writable).
1140 reinitialise it or call its C<ev_TYPE_set> macro.
1156 The file descriptor in the C<ev_io> watcher has become readable and/or
1191 watchers invoked before the event loop sleeps or polls for new events, and
1193 or lower priority within an event loop iteration.
1219 Not ever sent (or otherwise used) by libev itself, but can be freely used
1226 ran out of memory, a file descriptor was found to be closed or any other
1235 example it might indicate that a fd is readable or writable, and if your
1237 the error from read() or write(). This will not work in multi-threaded
1257 (or never started) and there are no pending events outstanding.
1304 the watcher was active or not).
1309 pending. If you want to free or reuse the memory used by the watcher it is
1349 You I<must not> change the priority of a watcher as long as it is active or
1354 or might not have been clamped to the valid range.
1385 Stopping the watcher, letting libev invoke it, or calling
1409 initialised. This can be done with a call to C<ev_TYPE_init>, or calls to
1414 will - as long as you either keep the memory contents intact, or call
1422 freed or anything else - the only legal thing is to keep a pointer to it,
1429 stay in this pending state until either it is stopped or its callback is
1433 The watcher might or might not be active while it is pending (for example,
1437 moved, freed or reused. And if it is active the rules described in the
1447 be pending), or explicitly by calling its C<ev_TYPE_stop> function. The
1449 of whether it was active or not, so stopping a watcher explicitly before
1491 Static (ordering) priorities are most useful when you have two or more
1502 will only be executed when no same or higher priority watchers have
1572 watcher is stopped to your hearts content), or I<[read-write]>, which
1575 sensible or take immediate effect (or do anything at all), but libev will
1576 not crash or malfunction in any way.
1579 =head2 C<ev_io> - is this file descriptor readable or writable?
1581 I/O watchers check whether a file descriptor is readable or writable
1582 in each iteration of the event loop, or, more precisely, when reading
1589 In general you can register as many read and/or write event watchers per
1615 descriptor (either due to calling C<close> explicitly or any other means,
1626 you I<have> to call C<ev_io_set> (or C<ev_io_init>) when you change the
1637 have C<dup ()>'ed file descriptors or weirder constellations, and register
1641 for potentially C<dup ()>'ed file descriptors, or to resort to
1642 C<EVBACKEND_SELECT> or C<EVBACKEND_POLL>.
1646 Many people try to use C<select> (or libev) on file descriptors
1653 always get a readiness notification instantly, and your read (or possibly
1665 convenience: sometimes you want to watch STDIN or STDOUT, which is
1666 usually a tty, often a pipe, but also sometimes files or special devices
1673 libeio), but use them when it is convenient, e.g. for STDIN/STDOUT, or
1679 Some backends (epoll, kqueue) do not support C<fork ()> at all or exhibit
1684 ()> after a fork in the child, enable C<EVFLAG_FORKCHECK>, or resort to
1685 C<EVBACKEND_SELECT> or C<EVBACKEND_POLL>.
1729 when you run into C<ENFILE> or C<EMFILE>, close it, run C<accept>,
1746 receive events for and C<events> is either C<EV_READ>, C<EV_WRITE> or
1769      .. read from stdin here (or from w->fd) and handle any I/O errors
1810 data or other life sign was received).
1841 successfully read or write some data. If you go into an idle state where
1860 whether the watcher is active or not:
1985 off after the first million or so of active timers, i.e. it's usually
2008 (500.9 truncated to the resolution) + 1, or 501.
2018 the callback at system time 502, or 1.1s after the timer was started.
2022 delay has actually elapsed, or in other words, it always errs on the "too
2053 Neither of these clocks is synchronised with each other or any other clock
2055 than C<gettimeofday ()> or C<time ()>. On a GNU/Linux system, for example,
2061 a second or so.
2065 or C<ev_now> from when you started your timer and when your callback is
2096 operating systems, OS versions or even different hardware.
2098 The other form of suspend (job control, or sending a SIGSTOP) will see a
2169 or C<ev_timer_again> is called, and determines the next timeout (if any),
2207 =head2 C<ev_periodic> - to cron or not to cron?
2212 Unlike C<ev_timer>, periodic watchers are not based on real time (or
2214 (absolute time, the thing you can read on your calender or clock). The
2215 difference is that wall clock time can run faster or slower than real
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
2256 will be stopped and invoked when the system clock reaches or surpasses
2274 full hour (UTC), or more correctly, when the system time is evenly divisible
2285 ten). Typical values for offset are, in fact, C<0> or something between
2300 NOTE: I<This callback MUST NOT stop or destroy any periodic watcher, ever,
2301 or make ANY other event loop modifications whatsoever, unless explicitly
2304 If you need to stop it, return C<now + 1e30> (or so, fudge fudge) and stop
2322 NOTE: I<< This callback must always return a time that is higher than or
2336 when you changed some parameters or the reschedule callback would return
2354 timer fires or C<ev_periodic_again> is being called.
2359 take effect when the periodic timer fires or C<ev_periodic_again> is being
2364 The current reschedule callback, or C<0>, if this functionality is
2366 the periodic timer fires or C<ev_periodic_again> is being called.
2372 Example: Call a callback every hour, or, more precisely, whenever the
2379      ... its now a full hour (UTC, or TAI or whatever your clock follows)
2409 signal one or more times. Even though signals are very asynchronous, libev
2429 C<SA_RESTART> (or equivalent) behaviour enabled, so system calls should
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
2470 When you want to use sigwait (or mix libev signal handling with your own
2472 all signals before creating any threads (or creating them with a fully set
2513 some child status changes (most typically when a child of yours dies or
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
2563 Configures the watcher to wait for status changes of process C<pid> (or
2569 activate the watcher when the process terminates) or C<1> (additionally
2570 activate the watcher when the process is stopped or continued).
2574 The process id this watcher watches out for, or C<0>, meaning any process id.
2620 C<stat> on that path in regular intervals (or when the OS says it changed)
2627 exist" (or more correctly "path cannot be stat'ed") is signified by the
2632 The path I<must not> end in a slash or contain special components such as
2633 C<.> or C<..>. The path I<should> be absolute: If it is relative and
2682 but as long as kernel 2.6.25 or newer is used (2.6.24 and older have too
2699 busy or the intervals between stat's are large, a stat call will be fast,
2723 than a second (or till slightly after the next full second boundary), using
2751 relative to the attributes at the time the watcher was started (or the
2765 C<ev_statdata>, this is usually the (or one of the) C<struct stat> types
2773 C<prev> != C<attr>, or, more precisely, one or more of these members
2844 Idle watchers trigger events when no other events of the same or higher
2848 That is, as long as your process is busy handling sockets or timeouts
2849 (or even signals, imagine) of the same or higher priority it will not be
2850 triggered. But when your process is idle (or only lower-priority watchers
2852 iteration - until stopped, that is, or your process receives more events
2860 "pseudo-background processing", or delay processing stuff to after the
2918 You I<must not> call C<ev_run> (or similar functions that enter the
2919 current event loop) or C<ev_loop_fork> from either C<ev_prepare> or
2928 variable changes, implement your own watchers, integrate net-snmp or a
2947 with priority higher than or equal to the event loop and one coroutine
2992 Initialises and configures the prepare or check watcher - they have no
3001 There are a number of principal ways to embed other event loops or modules
3011 priority for the check watcher or use C<ev_clear_pending> explicitly, as
3097 Method 4: Do not use a prepare or check watcher because the module you
3134 loop, other types of watchers might be handled in a delayed or incorrect
3279 in the child, or both parent in child, in effect "continuing" after the
3284 when I<either> the parent I<or> the child process continues.
3298 When this is not possible, or you want to use the default loop for
3361 In general, you cannot use an C<ev_loop> from multiple threads or other
3381 is that the author does not know of a simple (or any) algorithm for a
3383 need elaborate support such as pthreads or unportable memory access
3482 signal or similar contexts (see the discussion of C<EV_ATOMIC_T> in the
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
3527 or timeout without having to allocate/configure/start/stop/free one or
3540 C<EV_ERROR>, C<EV_READ>, C<EV_WRITE> or C<EV_TIMER>) and the C<arg>
3579 or modify at any time: libev will completely ignore it. This can be used
3624 the C<data> member of the watcher (for woozies or C++ coders), or you need
3656 used to cancel the operation, or do other things with it.
3674 delay invoking the callback by using a C<prepare> or C<idle> watcher for
3675 example, or more sneakily, by reusing an existing (stopped) watcher and
3692 a modal "Are you sure?" dialog is still waiting), or just the nested one
3693 and not the main one (e.g. user clocked "Ok" in a modal dialog), or some
3843 Whenever you want to start/stop a watcher or do other modifications to an
3865 kind of threads or coroutines, you might want to customise libev so that
3884 matter when, or whether the watcher is active or not when this function is
3896 this or any other coroutine.
3985 is compiled with a C++ compiler or your C and C++ environments allow
4005 that the watcher is associated with (or no additional members at all if
4015 conventions as your C compiler (for static member functions), or you have
4116 Also sets a callback, but uses a static method or plain function as
4137 with the same arguments. Either this method or a suitable start method
4321 execution of C<EV_DEFAULT>, C<EV_DEFAULT_> or C<ev_default_init (...)>.
4330 or not.
4352 you can easily upgrade by simply copying (or having a checked-out copy of
4357 Depending on what features you need you need to include one or more sets of files
4381 You need the following files in your source tree, or in a directory
4431 define before including (or compiling) any of its files. The default in
4475 link against libm or something equivalent. Enabling this when the C<floor>
4484 you usually have to link against librt or something similar. Enabling it
4508 the pthread dependency. Defaults to C<1> on GNU/Linux with glibc 2.x or
4522 2.7 or newer, otherwise disabled.
4526 If undefined or defined to be C<1>, libev will compile in support for the
4535 C<NFDBITS> or C<fd_mask> definition or it mis-guesses the bitset layout
4537 some low limit such as 1024 or might have other limitations (winsocket
4592 headers indicate GNU/Linux + Glibc 2.4 or newer, otherwise disabled.
4622 indicate GNU/Linux + Glibc 2.4 or newer, otherwise disabled.
4628 different cpus (or different cpu cores). This reduces dependencies
4640 Libev requires an integer type (suitable for storing C<0> or C<1>) whose
4641 access is atomic with respect to other threads or signal contexts. No
4676 If undefined or defined to C<1>, then all event-loop-specific functions
4690 The range of allowed priorities. C<EV_MINPRI> must be smaller or equal to
4707 If undefined or defined to be C<1> (and the platform supports it), then
4718 A typical way to use this symbol is to define it to C<0> (or to a bitset
4826 The highest supported signal number, +1 (or, the number of
4836 pid. The default size is C<16> (or C<1> with C<EV_FEATURES> disabled),
4843 inotify watch id. The default size is C<16> (or C<1> with C<EV_FEATURES>
4906 avoid the C<struct ev_loop *> as first argument in all cases, or to use
4990 If you want to know which design (one loop, locking, or multiple loops
4991 without or something else still) is best for your problem, then I cannot
4997 in that thread, or create a separate thread running only the default loop.
4999 This helps integrating other libraries or software modules that use libev
5017 (or from signal contexts...).
5019 An example use would be to communicate signals or other events that only
5043 Depending on your compiler and compiler settings, you might get no or a
5053 workarounds, or other changes to the code that make it less clear and less
5056 And of course, some compiler warnings are just plain stupid, or simply
5067 warnings, not errors, or proof of bugs.
5086 as if it were a bug in libev (e.g. in realloc or in the poll backend,
5087 although an acceptable workaround has been found here), or it might be
5111 files larger than 2GiB or so, which mainly affects C<ev_stat> watchers.
5124 you touch is broken, whether it is locales, poll, kqueue or even the
5174 releases. If you run into high CPU usage, your program freezes or you get
5217 either accept everything or return C<ENOBUFS> if the buffer is too large,
5225 more than a hundred or so sockets, then likely it needs to use a totally
5240 you do I<not> compile the F<ev.c> or any other embedded source files!):
5276 call (which might be in libev or elsewhere, for example, perl and many
5281 fetish or something like this inside Microsoft). You can increase this
5284 runtime libraries. This might get you to about C<512> or C<2048> sockets
5285 (depending on windows version and/or the phase of the moon). To get more,
5312 The type C<sig_atomic_t volatile> (or whatever is defined as
5322 thread" or will block signals process-wide, both behaviours would
5348 is either obsolete or somebody patched it to use C<long double> or
5376 =item Changing timer/periodic watchers (by autorepeat or calling again): O(log skipped_other_timers)
5383 These just add the watcher into an array or at the head of a list.
5391 have many watchers waiting for the same fd or signal: one is typical, two
5396 By virtue of using a binary or 4-heap, the next timer is always found at a
5401 A change means an I/O watcher gets started or stopped, which requires
5423 running async watchers or all signal numbers.
5518 for reading on a file descriptor, time having passed or simply not having
5521 In libev, events are represented as single bits (such as C<EV_READ> or