]> git.llucax.com Git - software/libev.git/blob - ev.pod
e409a0391fc68b62df8cb5c88c80390e177bcd54
[software/libev.git] / ev.pod
1 =head1 NAME
2
3 libev - a high performance full-featured event loop written in C
4
5 =head1 SYNOPSIS
6
7   #include <ev.h>
8
9 =head1 DESCRIPTION
10
11 Libev is an event loop: you register interest in certain events (such as a
12 file descriptor being readable or a timeout occuring), and it will manage
13 these event sources and provide your program events.
14
15 To do this, it must take more or less complete control over your process
16 (or thread) by executing the I<event loop> handler, and will then
17 communicate events via a callback mechanism.
18
19 You register interest in certain events by registering so-called I<event
20 watchers>, which are relatively small C structures you initialise with the
21 details of the event, and then hand it over to libev by I<starting> the
22 watcher.
23
24 =head1 FEATURES
25
26 Libev supports select, poll, the linux-specific epoll and the bsd-specific
27 kqueue mechanisms for file descriptor events, relative timers, absolute
28 timers with customised rescheduling, signal events, process status change
29 events (related to SIGCHLD), and event watchers dealing with the event
30 loop mechanism itself (idle, prepare and check watchers).
31
32 =head1 CONVENTIONS
33
34 Libev is very configurable. In this manual the default configuration
35 will be described, which supports multiple event loops. For more info
36 about various configuraiton options please have a look at the file
37 F<README.embed> in the libev distribution. If libev was configured without
38 support for multiple event loops, then all functions taking an initial
39 argument of name C<loop> (which is always of type C<struct ev_loop *>)
40 will not have this argument.
41
42 =head1 TIME AND OTHER GLOBAL FUNCTIONS
43
44 Libev represents time as a single floating point number. This type is
45 called C<ev_tstamp>, which is what you should use too. It usually aliases
46 to the double type in C.
47
48 =over 4
49
50 =item ev_tstamp ev_time ()
51
52 Returns the current time as libev would use it.
53
54 =item int ev_version_major ()
55
56 =item int ev_version_minor ()
57
58 You can find out the major and minor version numbers of the library
59 you linked against by calling the functions C<ev_version_major> and
60 C<ev_version_minor>. If you want, you can compare against the global
61 symbols C<EV_VERSION_MAJOR> and C<EV_VERSION_MINOR>, which specify the
62 version of the library your program was compiled against.
63
64 Usually, its a good idea to terminate if the major versions mismatch,
65 as this indicates an incompatible change.  Minor versions are usually
66 compatible to older versions, so a larger minor version alone is usually
67 not a problem.
68
69 =item ev_set_allocator (void *(*cb)(void *ptr, long size))
70
71 Sets the allocation function to use (the prototype is similar to the
72 realloc function). It is used to allocate and free memory (no surprises
73 here). If it returns zero when memory needs to be allocated, the library
74 might abort or take some potentially destructive action. The default is
75 your system realloc function.
76
77 You could override this function in high-availability programs to, say,
78 free some memory if it cannot allocate memory, to use a special allocator,
79 or even to sleep a while and retry until some memory is available.
80
81 =item ev_set_syserr_cb (void (*cb)(const char *msg));
82
83 Set the callback function to call on a retryable syscall error (such
84 as failed select, poll, epoll_wait). The message is a printable string
85 indicating the system call or subsystem causing the problem. If this
86 callback is set, then libev will expect it to remedy the sitution, no
87 matter what, when it returns. That is, libev will geenrally retry the
88 requested operation, or, if the condition doesn't go away, do bad stuff
89 (such as abort).
90
91 =back
92
93 =head1 FUNCTIONS CONTROLLING THE EVENT LOOP
94
95 An event loop is described by a C<struct ev_loop *>. The library knows two
96 types of such loops, the I<default> loop, which supports signals and child
97 events, and dynamically created loops which do not.
98
99 If you use threads, a common model is to run the default event loop
100 in your main thread (or in a separate thrad) and for each thread you
101 create, you also create another event loop. Libev itself does no lockign
102 whatsoever, so if you mix calls to different event loops, make sure you
103 lock (this is usually a bad idea, though, even if done right).
104
105 =over 4
106
107 =item struct ev_loop *ev_default_loop (unsigned int flags)
108
109 This will initialise the default event loop if it hasn't been initialised
110 yet and return it. If the default loop could not be initialised, returns
111 false. If it already was initialised it simply returns it (and ignores the
112 flags).
113
114 If you don't know what event loop to use, use the one returned from this
115 function.
116
117 The flags argument can be used to specify special behaviour or specific
118 backends to use, and is usually specified as 0 (or EVFLAG_AUTO)
119
120 It supports the following flags:
121
122 =over 4
123
124 =item EVFLAG_AUTO
125
126 The default flags value. Use this if you have no clue (its the right
127 thing, believe me).
128
129 =item EVFLAG_NOENV
130
131 If this flag bit is ored into the flag value then libev will I<not> look
132 at the environment variable C<LIBEV_FLAGS>. Otherwise (the default), this
133 environment variable will override the flags completely. This is useful
134 to try out specific backends to tets their performance, or to work around
135 bugs.
136
137 =item EVMETHOD_SELECT  portable select backend
138
139 =item EVMETHOD_POLL    poll backend (everywhere except windows)
140
141 =item EVMETHOD_EPOLL   linux only
142
143 =item EVMETHOD_KQUEUE  some bsds only
144
145 =item EVMETHOD_DEVPOLL solaris 8 only
146
147 =item EVMETHOD_PORT    solaris 10 only
148
149 If one or more of these are ored into the flags value, then only these
150 backends will be tried (in the reverse order as given here). If one are
151 specified, any backend will do.
152
153 =back
154
155 =item struct ev_loop *ev_loop_new (unsigned int flags)
156
157 Similar to C<ev_default_loop>, but always creates a new event loop that is
158 always distinct from the default loop. Unlike the default loop, it cannot
159 handle signal and child watchers, and attempts to do so will be greeted by
160 undefined behaviour (or a failed assertion if assertions are enabled).
161
162 =item ev_default_destroy ()
163
164 Destroys the default loop again (frees all memory and kernel state
165 etc.). This stops all registered event watchers (by not touching them in
166 any way whatsoever, although you cnanot rely on this :).
167
168 =item ev_loop_destroy (loop)
169
170 Like C<ev_default_destroy>, but destroys an event loop created by an
171 earlier call to C<ev_loop_new>.
172
173 =item ev_default_fork ()
174
175 This function reinitialises the kernel state for backends that have
176 one. Despite the name, you can call it anytime, but it makes most sense
177 after forking, in either the parent or child process (or both, but that
178 again makes little sense).
179
180 You I<must> call this function after forking if and only if you want to
181 use the event library in both processes. If you just fork+exec, you don't
182 have to call it.
183
184 The function itself is quite fast and its usually not a problem to call
185 it just in case after a fork. To make this easy, the function will fit in
186 quite nicely into a call to C<pthread_atfork>:
187
188     pthread_atfork (0, 0, ev_default_fork);
189
190 =item ev_loop_fork (loop)
191
192 Like C<ev_default_fork>, but acts on an event loop created by
193 C<ev_loop_new>. Yes, you have to call this on every allocated event loop
194 after fork, and how you do this is entirely your own problem.
195
196 =item unsigned int ev_method (loop)
197
198 Returns one of the C<EVMETHOD_*> flags indicating the event backend in
199 use.
200
201 =item ev_tstamp = ev_now (loop)
202
203 Returns the current "event loop time", which is the time the event loop
204 got events and started processing them. This timestamp does not change
205 as long as callbacks are being processed, and this is also the base time
206 used for relative timers. You can treat it as the timestamp of the event
207 occuring (or more correctly, the mainloop finding out about it).
208
209 =item ev_loop (loop, int flags)
210
211 Finally, this is it, the event handler. This function usually is called
212 after you initialised all your watchers and you want to start handling
213 events.
214
215 If the flags argument is specified as 0, it will not return until either
216 no event watchers are active anymore or C<ev_unloop> was called.
217
218 A flags value of C<EVLOOP_NONBLOCK> will look for new events, will handle
219 those events and any outstanding ones, but will not block your process in
220 case there are no events.
221
222 A flags value of C<EVLOOP_ONESHOT> will look for new events (waiting if
223 neccessary) and will handle those and any outstanding ones. It will block
224 your process until at least one new event arrives.
225
226 This flags value could be used to implement alternative looping
227 constructs, but the C<prepare> and C<check> watchers provide a better and
228 more generic mechanism.
229
230 =item ev_unloop (loop, how)
231
232 Can be used to make a call to C<ev_loop> return early. The C<how> argument
233 must be either C<EVUNLOOP_ONCE>, which will make the innermost C<ev_loop>
234 call return, or C<EVUNLOOP_ALL>, which will make all nested C<ev_loop>
235 calls return.
236
237 =item ev_ref (loop)
238
239 =item ev_unref (loop)
240
241 Ref/unref can be used to add or remove a refcount on the event loop: Every
242 watcher keeps one reference. If you have a long-runing watcher you never
243 unregister that should not keep ev_loop from running, ev_unref() after
244 starting, and ev_ref() before stopping it. Libev itself uses this for
245 example for its internal signal pipe: It is not visible to you as a user
246 and should not keep C<ev_loop> from exiting if the work is done. It is
247 also an excellent way to do this for generic recurring timers or from
248 within third-party libraries. Just remember to unref after start and ref
249 before stop.
250
251 =back
252
253 =head1 ANATOMY OF A WATCHER
254
255 A watcher is a structure that you create and register to record your
256 interest in some event. For instance, if you want to wait for STDIN to
257 become readable, you would create an ev_io watcher for that:
258
259   static void my_cb (struct ev_loop *loop, struct ev_io *w, int revents)
260   {
261     ev_io_stop (w);
262     ev_unloop (loop, EVUNLOOP_ALL);
263   }
264
265   struct ev_loop *loop = ev_default_loop (0);
266   struct ev_io stdin_watcher;
267   ev_init (&stdin_watcher, my_cb);
268   ev_io_set (&stdin_watcher, STDIN_FILENO, EV_READ);
269   ev_io_start (loop, &stdin_watcher);
270   ev_loop (loop, 0);
271
272 As you can see, you are responsible for allocating the memory for your
273 watcher structures (and it is usually a bad idea to do this on the stack,
274 although this can sometimes be quite valid).
275
276 Each watcher structure must be initialised by a call to C<ev_init
277 (watcher *, callback)>, which expects a callback to be provided. This
278 callback gets invoked each time the event occurs (or, in the case of io
279 watchers, each time the event loop detects that the file descriptor given
280 is readable and/or writable).
281
282 Each watcher type has its own C<< ev_<type>_set (watcher *, ...) >> macro
283 with arguments specific to this watcher type. There is also a macro
284 to combine initialisation and setting in one call: C<< ev_<type>_init
285 (watcher *, callback, ...) >>.
286
287 To make the watcher actually watch out for events, you have to start it
288 with a watcher-specific start function (C<< ev_<type>_start (loop, watcher
289 *) >>), and you can stop watching for events at any time by calling the
290 corresponding stop function (C<< ev_<type>_stop (loop, watcher *) >>.
291
292 As long as your watcher is active (has been started but not stopped) you
293 must not touch the values stored in it. Most specifically you must never
294 reinitialise it or call its set method.
295
296 You cna check wether an event is active by calling the C<ev_is_active
297 (watcher *)> macro. To see wether an event is outstanding (but the
298 callback for it has not been called yet) you cna use the C<ev_is_pending
299 (watcher *)> macro.
300
301 Each and every callback receives the event loop pointer as first, the
302 registered watcher structure as second, and a bitset of received events as
303 third argument.
304
305 The rceeived events usually include a single bit per event type received
306 (you can receive multiple events at the same time). The possible bit masks
307 are:
308
309 =over 4
310
311 =item EV_READ
312
313 =item EV_WRITE
314
315 The file descriptor in the ev_io watcher has become readable and/or
316 writable.
317
318 =item EV_TIMEOUT
319
320 The ev_timer watcher has timed out.
321
322 =item EV_PERIODIC
323
324 The ev_periodic watcher has timed out.
325
326 =item EV_SIGNAL
327
328 The signal specified in the ev_signal watcher has been received by a thread.
329
330 =item EV_CHILD
331
332 The pid specified in the ev_child watcher has received a status change.
333
334 =item EV_IDLE
335
336 The ev_idle watcher has determined that you have nothing better to do.
337
338 =item EV_PREPARE
339
340 =item EV_CHECK
341
342 All ev_prepare watchers are invoked just I<before> C<ev_loop> starts
343 to gather new events, and all ev_check watchers are invoked just after
344 C<ev_loop> has gathered them, but before it invokes any callbacks for any
345 received events. Callbacks of both watcher types can start and stop as
346 many watchers as they want, and all of them will be taken into account
347 (for example, a ev_prepare watcher might start an idle watcher to keep
348 C<ev_loop> from blocking).
349
350 =item EV_ERROR
351
352 An unspecified error has occured, the watcher has been stopped. This might
353 happen because the watcher could not be properly started because libev
354 ran out of memory, a file descriptor was found to be closed or any other
355 problem. You best act on it by reporting the problem and somehow coping
356 with the watcher being stopped.
357
358 Libev will usually signal a few "dummy" events together with an error,
359 for example it might indicate that a fd is readable or writable, and if
360 your callbacks is well-written it can just attempt the operation and cope
361 with the error from read() or write(). This will not work in multithreaded
362 programs, though, so beware.
363
364 =back
365
366 =head2 ASSOCIATING CUSTOM DATA WITH A WATCHER
367
368 Each watcher has, by default, a member C<void *data> that you can change
369 and read at any time, libev will completely ignore it. This cna be used
370 to associate arbitrary data with your watcher. If you need more data and
371 don't want to allocate memory and store a pointer to it in that data
372 member, you can also "subclass" the watcher type and provide your own
373 data:
374
375   struct my_io
376   {
377     struct ev_io io;
378     int otherfd;
379     void *somedata;
380     struct whatever *mostinteresting;
381   }
382
383 And since your callback will be called with a pointer to the watcher, you
384 can cast it back to your own type:
385
386   static void my_cb (struct ev_loop *loop, struct ev_io *w_, int revents)
387   {
388     struct my_io *w = (struct my_io *)w_;
389     ...
390   }
391
392 More interesting and less C-conformant ways of catsing your callback type
393 have been omitted....
394
395
396 =head1 WATCHER TYPES
397
398 This section describes each watcher in detail, but will not repeat
399 information given in the last section.
400
401 =head2 struct ev_io - is my file descriptor readable or writable
402
403 I/O watchers check wether a file descriptor is readable or writable
404 in each iteration of the event loop (This behaviour is called
405 level-triggering because you keep receiving events as long as the
406 condition persists. Remember you cna stop the watcher if you don't want to
407 act on the event and neither want to receive future events).
408
409 =over 4
410
411 =item ev_io_init (ev_io *, callback, int fd, int events)
412
413 =item ev_io_set (ev_io *, int fd, int events)
414
415 Configures an ev_io watcher. The fd is the file descriptor to rceeive
416 events for and events is either C<EV_READ>, C<EV_WRITE> or C<EV_READ |
417 EV_WRITE> to receive the given events.
418
419 =back
420
421 =head2 struct ev_timer - relative and optionally recurring timeouts
422
423 Timer watchers are simple relative timers that generate an event after a
424 given time, and optionally repeating in regular intervals after that.
425
426 The timers are based on real time, that is, if you register an event that
427 times out after an hour and youreset your system clock to last years
428 time, it will still time out after (roughly) and hour. "Roughly" because
429 detecting time jumps is hard, and soem inaccuracies are unavoidable (the
430 monotonic clock option helps a lot here).
431
432 =over 4
433
434 =item ev_timer_init (ev_timer *, callback, ev_tstamp after, ev_tstamp repeat)
435
436 =item ev_timer_set (ev_timer *, ev_tstamp after, ev_tstamp repeat)
437
438 Configure the timer to trigger after C<after> seconds. If C<repeat> is
439 C<0.>, then it will automatically be stopped. If it is positive, then the
440 timer will automatically be configured to trigger again C<repeat> seconds
441 later, again, and again, until stopped manually.
442
443 The timer itself will do a best-effort at avoiding drift, that is, if you
444 configure a timer to trigger every 10 seconds, then it will trigger at
445 exactly 10 second intervals. If, however, your program cannot keep up with
446 the timer (ecause it takes longer than those 10 seconds to do stuff) the
447 timer will not fire more than once per event loop iteration.
448
449 =item ev_timer_again (loop)
450
451 This will act as if the timer timed out and restart it again if it is
452 repeating. The exact semantics are:
453
454 If the timer is started but nonrepeating, stop it.
455
456 If the timer is repeating, either start it if necessary (with the repeat
457 value), or reset the running timer to the repeat value.
458
459 This sounds a bit complicated, but here is a useful and typical
460 example: Imagine you have a tcp connection and you want a so-called idle
461 timeout, that is, you want to be called when there have been, say, 60
462 seconds of inactivity on the socket. The easiest way to do this is to
463 configure an ev_timer with after=repeat=60 and calling ev_timer_again each
464 time you successfully read or write some data. If you go into an idle
465 state where you do not expect data to travel on the socket, you can stop
466 the timer, and again will automatically restart it if need be.
467
468 =back
469
470 =head2 ev_periodic
471
472 Periodic watchers are also timers of a kind, but they are very versatile
473 (and unfortunately a bit complex).
474
475 Unlike ev_timer's, they are not based on real time (or relative time)
476 but on wallclock time (absolute time). You can tell a periodic watcher
477 to trigger "at" some specific point in time. For example, if you tell a
478 periodic watcher to trigger in 10 seconds (by specifiying e.g. c<ev_now ()
479 + 10.>) and then reset your system clock to the last year, then it will
480 take a year to trigger the event (unlike an ev_timer, which would trigger
481 roughly 10 seconds later and of course not if you reset your system time
482 again).
483
484 They can also be used to implement vastly more complex timers, such as
485 triggering an event on eahc midnight, local time.
486
487 =over 4
488
489 =item ev_periodic_init (ev_periodic *, callback, ev_tstamp at, ev_tstamp interval, reschedule_cb)
490
491 =item ev_periodic_set (ev_periodic *, ev_tstamp after, ev_tstamp repeat, reschedule_cb)
492
493 Lots of arguments, lets sort it out... There are basically three modes of
494 operation, and we will explain them from simplest to complex:
495
496
497 =over 4
498
499 =item * absolute timer (interval = reschedule_cb = 0)
500
501 In this configuration the watcher triggers an event at the wallclock time
502 C<at> and doesn't repeat. It will not adjust when a time jump occurs,
503 that is, if it is to be run at January 1st 2011 then it will run when the
504 system time reaches or surpasses this time.
505
506 =item * non-repeating interval timer (interval > 0, reschedule_cb = 0)
507
508 In this mode the watcher will always be scheduled to time out at the next
509 C<at + N * interval> time (for some integer N) and then repeat, regardless
510 of any time jumps.
511
512 This can be used to create timers that do not drift with respect to system
513 time:
514
515    ev_periodic_set (&periodic, 0., 3600., 0);
516
517 This doesn't mean there will always be 3600 seconds in between triggers,
518 but only that the the callback will be called when the system time shows a
519 full hour (UTC), or more correct, when the system time is evenly divisible
520 by 3600.
521
522 Another way to think about it (for the mathematically inclined) is that
523 ev_periodic will try to run the callback in this mode at the next possible
524 time where C<time = at (mod interval)>, regardless of any time jumps.
525
526 =item * manual reschedule mode (reschedule_cb = callback)
527
528 In this mode the values for C<interval> and C<at> are both being
529 ignored. Instead, each time the periodic watcher gets scheduled, the
530 reschedule callback will be called with the watcher as first, and the
531 current time as second argument.
532
533 NOTE: I<This callback MUST NOT stop or destroy the periodic or any other
534 periodic watcher, ever, or make any event loop modificstions>. If you need
535 to stop it, return 1e30 (or so, fudge fudge) and stop it afterwards.
536
537 Its prototype is c<ev_tstamp (*reschedule_cb)(struct ev_periodic *w,
538 ev_tstamp now)>, e.g.:
539
540    static ev_tstamp my_rescheduler (struct ev_periodic *w, ev_tstamp now)
541    {
542      return now + 60.;
543    }
544
545 It must return the next time to trigger, based on the passed time value
546 (that is, the lowest time value larger than to the second argument). It
547 will usually be called just before the callback will be triggered, but
548 might be called at other times, too.
549
550 This can be used to create very complex timers, such as a timer that
551 triggers on each midnight, local time. To do this, you would calculate the
552 next midnight after C<now> and return the timestamp value for this. How you do this
553 is, again, up to you (but it is not trivial).
554
555 =back
556
557 =item ev_periodic_again (loop, ev_periodic *)
558
559 Simply stops and restarts the periodic watcher again. This is only useful
560 when you changed some parameters or the reschedule callback would return
561 a different time than the last time it was called (e.g. in a crond like
562 program when the crontabs have changed).
563
564 =back
565
566 =head2 ev_signal - signal me when a signal gets signalled
567
568 Signal watchers will trigger an event when the process receives a specific
569 signal one or more times. Even though signals are very asynchronous, libev
570 will try its best to deliver signals synchronously, i.e. as part of the
571 normal event processing, like any other event.
572
573 You cna configure as many watchers as you like per signal. Only when the
574 first watcher gets started will libev actually register a signal watcher
575 with the kernel (thus it coexists with your own signal handlers as long
576 as you don't register any with libev). Similarly, when the last signal
577 watcher for a signal is stopped libev will reset the signal handler to
578 SIG_DFL (regardless of what it was set to before).
579
580 =over 4
581
582 =item ev_signal_init (ev_signal *, callback, int signum)
583
584 =item ev_signal_set (ev_signal *, int signum)
585
586 Configures the watcher to trigger on the given signal number (usually one
587 of the C<SIGxxx> constants).
588
589 =back
590
591 =head2 ev_child - wait for pid status changes
592
593 Child watchers trigger when your process receives a SIGCHLD in response to
594 some child status changes (most typically when a child of yours dies).
595
596 =over 4
597
598 =item ev_child_init (ev_child *, callback, int pid)
599
600 =item ev_child_set (ev_child *, int pid)
601
602 Configures the watcher to wait for status changes of process C<pid> (or
603 I<any> process if C<pid> is specified as C<0>). The callback can look
604 at the C<rstatus> member of the C<ev_child> watcher structure to see
605 the status word (use the macros from C<sys/wait.h>). The C<rpid> member
606 contains the pid of the process causing the status change.
607
608 =back
609
610 =head2 ev_idle - when you've got nothing better to do
611
612 Idle watchers trigger events when there are no other I/O or timer (or
613 periodic) events pending. That is, as long as your process is busy
614 handling sockets or timeouts it will not be called. But when your process
615 is idle all idle watchers are being called again and again - until
616 stopped, that is, or your process receives more events.
617
618 The most noteworthy effect is that as long as any idle watchers are
619 active, the process will not block when waiting for new events.
620
621 Apart from keeping your process non-blocking (which is a useful
622 effect on its own sometimes), idle watchers are a good place to do
623 "pseudo-background processing", or delay processing stuff to after the
624 event loop has handled all outstanding events.
625
626 =over 4
627
628 =item ev_idle_init (ev_signal *, callback)
629
630 Initialises and configures the idle watcher - it has no parameters of any
631 kind. There is a C<ev_idle_set> macro, but using it is utterly pointless,
632 believe me.
633
634 =back
635
636 =head2 prepare and check - your hooks into the event loop
637
638 Prepare and check watchers usually (but not always) are used in
639 tandom. Prepare watchers get invoked before the process blocks and check
640 watchers afterwards.
641
642 Their main purpose is to integrate other event mechanisms into libev. This
643 could be used, for example, to track variable changes, implement your own
644 watchers, integrate net-snmp or a coroutine library and lots more.
645
646 This is done by examining in each prepare call which file descriptors need
647 to be watched by the other library, registering ev_io watchers for them
648 and starting an ev_timer watcher for any timeouts (many libraries provide
649 just this functionality). Then, in the check watcher you check for any
650 events that occured (by making your callbacks set soem flags for example)
651 and call back into the library.
652
653 As another example, the perl Coro module uses these hooks to integrate
654 coroutines into libev programs, by yielding to other active coroutines
655 during each prepare and only letting the process block if no coroutines
656 are ready to run.
657
658 =over 4
659
660 =item ev_prepare_init (ev_prepare *, callback)
661
662 =item ev_check_init (ev_check *, callback)
663
664 Initialises and configures the prepare or check watcher - they have no
665 parameters of any kind. There are C<ev_prepare_set> and C<ev_check_set>
666 macros, but using them is utterly, utterly pointless.
667
668 =back
669
670 =head1 OTHER FUNCTIONS
671
672 There are some other fucntions of possible interest. Described. Here. Now.
673
674 =over 4
675
676 =item ev_once (loop, int fd, int events, ev_tstamp timeout, callback)
677
678 This function combines a simple timer and an I/O watcher, calls your
679 callback on whichever event happens first and automatically stop both
680 watchers. This is useful if you want to wait for a single event on an fd
681 or timeout without havign to allocate/configure/start/stop/free one or
682 more watchers yourself.
683
684 If C<fd> is less than 0, then no I/O watcher will be started and events is
685 ignored. Otherwise, an ev_io watcher for the given C<fd> and C<events> set
686 will be craeted and started.
687
688 If C<timeout> is less than 0, then no timeout watcher will be
689 started. Otherwise an ev_timer watcher with after = C<timeout> (and repeat
690 = 0) will be started.
691
692 The callback has the type C<void (*cb)(int revents, void *arg)> and
693 gets passed an events set (normally a combination of EV_ERROR, EV_READ,
694 EV_WRITE or EV_TIMEOUT) and the C<arg> value passed to C<ev_once>:
695
696   static void stdin_ready (int revents, void *arg)
697   {
698     if (revents & EV_TIMEOUT)
699       /* doh, nothing entered */
700     else if (revents & EV_READ)
701       /* stdin might have data for us, joy! */
702   }
703
704   ev_once (STDIN_FILENO, EV_READm 10., stdin_ready, 0);
705
706 =item ev_feed_event (loop, watcher, int events)
707
708 Feeds the given event set into the event loop, as if the specified event
709 has happened for the specified watcher (which must be a pointer to an
710 initialised but not necessarily active event watcher).
711
712 =item ev_feed_fd_event (loop, int fd, int revents)
713
714 Feed an event on the given fd, as if a file descriptor backend detected it.
715
716 =item ev_feed_signal_event (loop, int signum)
717
718 Feed an event as if the given signal occured (loop must be the default loop!).
719
720 =back
721
722 =head1 AUTHOR
723
724 Marc Lehmann <libev@schmorp.de>.
725