ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/libev/ev.pod
(Generate patch)

Comparing libev/ev.pod (file contents):
Revision 1.27 by root, Wed Nov 14 05:02:07 2007 UTC vs.
Revision 1.31 by root, Fri Nov 23 05:00:45 2007 UTC

75Usually, it's a good idea to terminate if the major versions mismatch, 75Usually, it's a good idea to terminate if the major versions mismatch,
76as this indicates an incompatible change. Minor versions are usually 76as this indicates an incompatible change. Minor versions are usually
77compatible to older versions, so a larger minor version alone is usually 77compatible to older versions, so a larger minor version alone is usually
78not a problem. 78not a problem.
79 79
80=item unsigned int ev_supported_backends ()
81
82Return the set of all backends (i.e. their corresponding C<EV_BACKEND_*>
83value) compiled into this binary of libev (independent of their
84availability on the system you are running on). See C<ev_default_loop> for
85a description of the set values.
86
87=item unsigned int ev_recommended_backends ()
88
89Return the set of all backends compiled into this binary of libev and also
90recommended for this platform. This set is often smaller than the one
91returned by C<ev_supported_backends>, as for example kqueue is broken on
92most BSDs and will not be autodetected unless you explicitly request it
93(assuming you know what you are doing). This is the set of backends that
94C<EVFLAG_AUTO> will probe for.
95
80=item ev_set_allocator (void *(*cb)(void *ptr, long size)) 96=item ev_set_allocator (void *(*cb)(void *ptr, long size))
81 97
82Sets the allocation function to use (the prototype is similar to the 98Sets the allocation function to use (the prototype is similar to the
83realloc C function, the semantics are identical). It is used to allocate 99realloc C function, the semantics are identical). It is used to allocate
84and free memory (no surprises here). If it returns zero when memory 100and free memory (no surprises here). If it returns zero when memory
119=item struct ev_loop *ev_default_loop (unsigned int flags) 135=item struct ev_loop *ev_default_loop (unsigned int flags)
120 136
121This will initialise the default event loop if it hasn't been initialised 137This will initialise the default event loop if it hasn't been initialised
122yet and return it. If the default loop could not be initialised, returns 138yet and return it. If the default loop could not be initialised, returns
123false. If it already was initialised it simply returns it (and ignores the 139false. If it already was initialised it simply returns it (and ignores the
124flags). 140flags. If that is troubling you, check C<ev_backend ()> afterwards).
125 141
126If you don't know what event loop to use, use the one returned from this 142If you don't know what event loop to use, use the one returned from this
127function. 143function.
128 144
129The flags argument can be used to specify special behaviour or specific 145The flags argument can be used to specify special behaviour or specific
130backends to use, and is usually specified as 0 (or EVFLAG_AUTO). 146backends to use, and is usually specified as C<0> (or EVFLAG_AUTO).
131 147
132It supports the following flags: 148It supports the following flags:
133 149
134=over 4 150=over 4
135 151
145C<LIBEV_FLAGS>. Otherwise (the default), this environment variable will 161C<LIBEV_FLAGS>. Otherwise (the default), this environment variable will
146override the flags completely if it is found in the environment. This is 162override the flags completely if it is found in the environment. This is
147useful to try out specific backends to test their performance, or to work 163useful to try out specific backends to test their performance, or to work
148around bugs. 164around bugs.
149 165
150=item C<EVMETHOD_SELECT> (portable select backend) 166=item C<EVBACKEND_SELECT> (value 1, portable select backend)
151 167
168This is your standard select(2) backend. Not I<completely> standard, as
169libev tries to roll its own fd_set with no limits on the number of fds,
170but if that fails, expect a fairly low limit on the number of fds when
171using this backend. It doesn't scale too well (O(highest_fd)), but its usually
172the fastest backend for a low number of fds.
173
152=item C<EVMETHOD_POLL> (poll backend, available everywhere except on windows) 174=item C<EVBACKEND_POLL> (value 2, poll backend, available everywhere except on windows)
153 175
154=item C<EVMETHOD_EPOLL> (linux only) 176And this is your standard poll(2) backend. It's more complicated than
177select, but handles sparse fds better and has no artificial limit on the
178number of fds you can use (except it will slow down considerably with a
179lot of inactive fds). It scales similarly to select, i.e. O(total_fds).
155 180
156=item C<EVMETHOD_KQUEUE> (some bsds only) 181=item C<EVBACKEND_EPOLL> (value 4, Linux)
157 182
158=item C<EVMETHOD_DEVPOLL> (solaris 8 only) 183For few fds, this backend is a bit little slower than poll and select,
184but it scales phenomenally better. While poll and select usually scale like
185O(total_fds) where n is the total number of fds (or the highest fd), epoll scales
186either O(1) or O(active_fds).
159 187
160=item C<EVMETHOD_PORT> (solaris 10 only) 188While stopping and starting an I/O watcher in the same iteration will
189result in some caching, there is still a syscall per such incident
190(because the fd could point to a different file description now), so its
191best to avoid that. Also, dup()ed file descriptors might not work very
192well if you register events for both fds.
193
194=item C<EVBACKEND_KQUEUE> (value 8, most BSD clones)
195
196Kqueue deserves special mention, as at the time of this writing, it
197was broken on all BSDs except NetBSD (usually it doesn't work with
198anything but sockets and pipes, except on Darwin, where of course its
199completely useless). For this reason its not being "autodetected" unless
200you explicitly specify the flags (i.e. you don't use EVFLAG_AUTO).
201
202It scales in the same way as the epoll backend, but the interface to the
203kernel is more efficient (which says nothing about its actual speed, of
204course). While starting and stopping an I/O watcher does not cause an
205extra syscall as with epoll, it still adds up to four event changes per
206incident, so its best to avoid that.
207
208=item C<EVBACKEND_DEVPOLL> (value 16, Solaris 8)
209
210This is not implemented yet (and might never be).
211
212=item C<EVBACKEND_PORT> (value 32, Solaris 10)
213
214This uses the Solaris 10 port mechanism. As with everything on Solaris,
215it's really slow, but it still scales very well (O(active_fds)).
216
217=item C<EVBACKEND_ALL>
218
219Try all backends (even potentially broken ones that wouldn't be tried
220with C<EVFLAG_AUTO>). Since this is a mask, you can do stuff such as
221C<EVBACKEND_ALL & ~EVBACKEND_KQUEUE>.
222
223=back
161 224
162If one or more of these are ored into the flags value, then only these 225If one or more of these are ored into the flags value, then only these
163backends will be tried (in the reverse order as given here). If one are 226backends will be tried (in the reverse order as given here). If none are
164specified, any backend will do. 227specified, most compiled-in backend will be tried, usually in reverse
165 228order of their flag values :)
166=back
167 229
168=item struct ev_loop *ev_loop_new (unsigned int flags) 230=item struct ev_loop *ev_loop_new (unsigned int flags)
169 231
170Similar to C<ev_default_loop>, but always creates a new event loop that is 232Similar to C<ev_default_loop>, but always creates a new event loop that is
171always distinct from the default loop. Unlike the default loop, it cannot 233always distinct from the default loop. Unlike the default loop, it cannot
188This function reinitialises the kernel state for backends that have 250This function reinitialises the kernel state for backends that have
189one. Despite the name, you can call it anytime, but it makes most sense 251one. Despite the name, you can call it anytime, but it makes most sense
190after forking, in either the parent or child process (or both, but that 252after forking, in either the parent or child process (or both, but that
191again makes little sense). 253again makes little sense).
192 254
193You I<must> call this function after forking if and only if you want to 255You I<must> call this function in the child process after forking if and
194use the event library in both processes. If you just fork+exec, you don't 256only if you want to use the event library in both processes. If you just
195have to call it. 257fork+exec, you don't have to call it.
196 258
197The function itself is quite fast and it's usually not a problem to call 259The function itself is quite fast and it's usually not a problem to call
198it just in case after a fork. To make this easy, the function will fit in 260it just in case after a fork. To make this easy, the function will fit in
199quite nicely into a call to C<pthread_atfork>: 261quite nicely into a call to C<pthread_atfork>:
200 262
201 pthread_atfork (0, 0, ev_default_fork); 263 pthread_atfork (0, 0, ev_default_fork);
202 264
265At the moment, C<EVBACKEND_SELECT> and C<EVBACKEND_POLL> are safe to use
266without calling this function, so if you force one of those backends you
267do not need to care.
268
203=item ev_loop_fork (loop) 269=item ev_loop_fork (loop)
204 270
205Like C<ev_default_fork>, but acts on an event loop created by 271Like C<ev_default_fork>, but acts on an event loop created by
206C<ev_loop_new>. Yes, you have to call this on every allocated event loop 272C<ev_loop_new>. Yes, you have to call this on every allocated event loop
207after fork, and how you do this is entirely your own problem. 273after fork, and how you do this is entirely your own problem.
208 274
209=item unsigned int ev_method (loop) 275=item unsigned int ev_backend (loop)
210 276
211Returns one of the C<EVMETHOD_*> flags indicating the event backend in 277Returns one of the C<EVBACKEND_*> flags indicating the event backend in
212use. 278use.
213 279
214=item ev_tstamp ev_now (loop) 280=item ev_tstamp ev_now (loop)
215 281
216Returns the current "event loop time", which is the time the event loop 282Returns the current "event loop time", which is the time the event loop
322*) >>), and you can stop watching for events at any time by calling the 388*) >>), and you can stop watching for events at any time by calling the
323corresponding stop function (C<< ev_<type>_stop (loop, watcher *) >>. 389corresponding stop function (C<< ev_<type>_stop (loop, watcher *) >>.
324 390
325As long as your watcher is active (has been started but not stopped) you 391As long as your watcher is active (has been started but not stopped) you
326must not touch the values stored in it. Most specifically you must never 392must not touch the values stored in it. Most specifically you must never
327reinitialise it or call its set method. 393reinitialise it or call its set macro.
328 394
329You can check whether an event is active by calling the C<ev_is_active 395You can check whether an event is active by calling the C<ev_is_active
330(watcher *)> macro. To see whether an event is outstanding (but the 396(watcher *)> macro. To see whether an event is outstanding (but the
331callback for it has not been called yet) you can use the C<ev_is_pending 397callback for it has not been called yet) you can use the C<ev_is_pending
332(watcher *)> macro. 398(watcher *)> macro.
449descriptors correctly if you register interest in two or more fds pointing 515descriptors correctly if you register interest in two or more fds pointing
450to the same underlying file/socket etc. description (that is, they share 516to the same underlying file/socket etc. description (that is, they share
451the same underlying "file open"). 517the same underlying "file open").
452 518
453If you must do this, then force the use of a known-to-be-good backend 519If you must do this, then force the use of a known-to-be-good backend
454(at the time of this writing, this includes only EVMETHOD_SELECT and 520(at the time of this writing, this includes only C<EVBACKEND_SELECT> and
455EVMETHOD_POLL). 521C<EVBACKEND_POLL>).
456 522
457=over 4 523=over 4
458 524
459=item ev_io_init (ev_io *, callback, int fd, int events) 525=item ev_io_init (ev_io *, callback, int fd, int events)
460 526
472given time, and optionally repeating in regular intervals after that. 538given time, and optionally repeating in regular intervals after that.
473 539
474The timers are based on real time, that is, if you register an event that 540The timers are based on real time, that is, if you register an event that
475times out after an hour and you reset your system clock to last years 541times out after an hour and you reset your system clock to last years
476time, it will still time out after (roughly) and hour. "Roughly" because 542time, it will still time out after (roughly) and hour. "Roughly" because
477detecting time jumps is hard, and soem inaccuracies are unavoidable (the 543detecting time jumps is hard, and some inaccuracies are unavoidable (the
478monotonic clock option helps a lot here). 544monotonic clock option helps a lot here).
479 545
480The relative timeouts are calculated relative to the C<ev_now ()> 546The relative timeouts are calculated relative to the C<ev_now ()>
481time. This is usually the right thing as this timestamp refers to the time 547time. This is usually the right thing as this timestamp refers to the time
482of the event triggering whatever timeout you are modifying/starting. If 548of the event triggering whatever timeout you are modifying/starting. If
483you suspect event processing to be delayed and you *need* to base the timeout 549you suspect event processing to be delayed and you I<need> to base the timeout
484on the current time, use something like this to adjust for this: 550on the current time, use something like this to adjust for this:
485 551
486 ev_timer_set (&timer, after + ev_now () - ev_time (), 0.); 552 ev_timer_set (&timer, after + ev_now () - ev_time (), 0.);
553
554The callback is guarenteed to be invoked only when its timeout has passed,
555but if multiple timers become ready during the same loop iteration then
556order of execution is undefined.
487 557
488=over 4 558=over 4
489 559
490=item ev_timer_init (ev_timer *, callback, ev_tstamp after, ev_tstamp repeat) 560=item ev_timer_init (ev_timer *, callback, ev_tstamp after, ev_tstamp repeat)
491 561
538again). 608again).
539 609
540They can also be used to implement vastly more complex timers, such as 610They can also be used to implement vastly more complex timers, such as
541triggering an event on eahc midnight, local time. 611triggering an event on eahc midnight, local time.
542 612
613As with timers, the callback is guarenteed to be invoked only when the
614time (C<at>) has been passed, but if multiple periodic timers become ready
615during the same loop iteration then order of execution is undefined.
616
543=over 4 617=over 4
544 618
545=item ev_periodic_init (ev_periodic *, callback, ev_tstamp at, ev_tstamp interval, reschedule_cb) 619=item ev_periodic_init (ev_periodic *, callback, ev_tstamp at, ev_tstamp interval, reschedule_cb)
546 620
547=item ev_periodic_set (ev_periodic *, ev_tstamp after, ev_tstamp repeat, reschedule_cb) 621=item ev_periodic_set (ev_periodic *, ev_tstamp after, ev_tstamp repeat, reschedule_cb)
548 622
549Lots of arguments, lets sort it out... There are basically three modes of 623Lots of arguments, lets sort it out... There are basically three modes of
550operation, and we will explain them from simplest to complex: 624operation, and we will explain them from simplest to complex:
551
552 625
553=over 4 626=over 4
554 627
555=item * absolute timer (interval = reschedule_cb = 0) 628=item * absolute timer (interval = reschedule_cb = 0)
556 629

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines