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

Comparing libev/ev.pod (file contents):
Revision 1.199 by root, Thu Oct 23 07:18:21 2008 UTC vs.
Revision 1.208 by root, Wed Oct 29 10:24:23 2008 UTC

… …
10 10
11 // a single header file is required 11 // a single header file is required
12 #include <ev.h> 12 #include <ev.h>
13 13
14 // every watcher type has its own typedef'd struct 14 // every watcher type has its own typedef'd struct
15 // with the name ev_<type> 15 // with the name ev_TYPE
16 ev_io stdin_watcher; 16 ev_io stdin_watcher;
17 ev_timer timeout_watcher; 17 ev_timer timeout_watcher;
18 18
19 // all watcher callbacks have a similar signature 19 // all watcher callbacks have a similar signature
20 // this callback is called when data is readable on stdin 20 // this callback is called when data is readable on stdin
… …
276 276
277=back 277=back
278 278
279=head1 FUNCTIONS CONTROLLING THE EVENT LOOP 279=head1 FUNCTIONS CONTROLLING THE EVENT LOOP
280 280
281An event loop is described by a C<ev_loop *>. The library knows two 281An event loop is described by a C<struct ev_loop *> (the C<struct>
282types of such loops, the I<default> loop, which supports signals and child 282is I<not> optional in this case, as there is also an C<ev_loop>
283events, and dynamically created loops which do not. 283I<function>).
284
285The library knows two types of such loops, the I<default> loop, which
286supports signals and child events, and dynamically created loops which do
287not.
284 288
285=over 4 289=over 4
286 290
287=item struct ev_loop *ev_default_loop (unsigned int flags) 291=item struct ev_loop *ev_default_loop (unsigned int flags)
288 292
… …
294If you don't know what event loop to use, use the one returned from this 298If you don't know what event loop to use, use the one returned from this
295function. 299function.
296 300
297Note that this function is I<not> thread-safe, so if you want to use it 301Note that this function is I<not> thread-safe, so if you want to use it
298from multiple threads, you have to lock (note also that this is unlikely, 302from multiple threads, you have to lock (note also that this is unlikely,
299as loops cannot bes hared easily between threads anyway). 303as loops cannot be shared easily between threads anyway).
300 304
301The default loop is the only loop that can handle C<ev_signal> and 305The default loop is the only loop that can handle C<ev_signal> and
302C<ev_child> watchers, and to do this, it always registers a handler 306C<ev_child> watchers, and to do this, it always registers a handler
303for C<SIGCHLD>. If this is a problem for your application you can either 307for C<SIGCHLD>. If this is a problem for your application you can either
304create a dynamic loop with C<ev_loop_new> that doesn't do that, or you 308create a dynamic loop with C<ev_loop_new> that doesn't do that, or you
… …
380=item C<EVBACKEND_EPOLL> (value 4, Linux) 384=item C<EVBACKEND_EPOLL> (value 4, Linux)
381 385
382For few fds, this backend is a bit little slower than poll and select, 386For few fds, this backend is a bit little slower than poll and select,
383but it scales phenomenally better. While poll and select usually scale 387but it scales phenomenally better. While poll and select usually scale
384like O(total_fds) where n is the total number of fds (or the highest fd), 388like O(total_fds) where n is the total number of fds (or the highest fd),
385epoll scales either O(1) or O(active_fds). The epoll design has a number 389epoll scales either O(1) or O(active_fds).
386of shortcomings, such as silently dropping events in some hard-to-detect 390
387cases and requiring a system call per fd change, no fork support and bad 391The epoll syscalls are the most misdesigned of the more advanced event
388support for dup. 392mechanisms: problems include silently dropping fds, requiring a system
393call per change per fd (and unnecessary guessing of parameters), problems
394with dup and so on. The biggest issue is fork races, however - if a
395program forks then I<both> parent and child process have to recreate the
396epoll set, which can take considerable time (one syscall per fd) and is of
397course hard to detect.
398
399Epoll is also notoriously buggy - embedding epoll fds should work, but
400of course doesn't, and epoll just loves to report events for totally
401I<different> file descriptors (even already closed ones, so one cannot
402even remove them from the set) than registered in the set (especially
403on SMP systems). Libev tries to counter these spurious notifications by
404employing an additional generation counter and comparing that against the
405events to filter out spurious ones.
389 406
390While stopping, setting and starting an I/O watcher in the same iteration 407While stopping, setting and starting an I/O watcher in the same iteration
391will result in some caching, there is still a system call per such incident 408will result in some caching, there is still a system call per such incident
392(because the fd could point to a different file description now), so its 409(because the fd could point to a different file description now), so its
393best to avoid that. Also, C<dup ()>'ed file descriptors might not work 410best to avoid that. Also, C<dup ()>'ed file descriptors might not work
394very well if you register events for both fds. 411very well if you register events for both fds.
395 412
396Please note that epoll sometimes generates spurious notifications, so you
397need to use non-blocking I/O or other means to avoid blocking when no data
398(or space) is available.
399
400Best performance from this backend is achieved by not unregistering all 413Best performance from this backend is achieved by not unregistering all
401watchers for a file descriptor until it has been closed, if possible, 414watchers for a file descriptor until it has been closed, if possible,
402i.e. keep at least one watcher active per fd at all times. Stopping and 415i.e. keep at least one watcher active per fd at all times. Stopping and
403starting a watcher (without re-setting it) also usually doesn't cause 416starting a watcher (without re-setting it) also usually doesn't cause
404extra overhead. 417extra overhead. A fork can both result in spurious notifications as well
418as in libev having to destroy and recreate the epoll object, which can
419take considerable time and thus should be avoided.
405 420
406While nominally embeddable in other event loops, this feature is broken in 421While nominally embeddable in other event loops, this feature is broken in
407all kernel versions tested so far. 422all kernel versions tested so far.
408 423
409This backend maps C<EV_READ> and C<EV_WRITE> in the same way as 424This backend maps C<EV_READ> and C<EV_WRITE> in the same way as
… …
424 439
425It scales in the same way as the epoll backend, but the interface to the 440It scales in the same way as the epoll backend, but the interface to the
426kernel is more efficient (which says nothing about its actual speed, of 441kernel is more efficient (which says nothing about its actual speed, of
427course). While stopping, setting and starting an I/O watcher does never 442course). While stopping, setting and starting an I/O watcher does never
428cause an extra system call as with C<EVBACKEND_EPOLL>, it still adds up to 443cause an extra system call as with C<EVBACKEND_EPOLL>, it still adds up to
429two event changes per incident. Support for C<fork ()> is very bad and it 444two event changes per incident. Support for C<fork ()> is very bad (but
430drops fds silently in similarly hard-to-detect cases. 445sane, unlike epoll) and it drops fds silently in similarly hard-to-detect
446cases
431 447
432This backend usually performs well under most conditions. 448This backend usually performs well under most conditions.
433 449
434While nominally embeddable in other event loops, this doesn't work 450While nominally embeddable in other event loops, this doesn't work
435everywhere, so you might need to test for this. And since it is broken 451everywhere, so you might need to test for this. And since it is broken
… …
464might perform better. 480might perform better.
465 481
466On the positive side, with the exception of the spurious readiness 482On the positive side, with the exception of the spurious readiness
467notifications, this backend actually performed fully to specification 483notifications, this backend actually performed fully to specification
468in all tests and is fully embeddable, which is a rare feat among the 484in all tests and is fully embeddable, which is a rare feat among the
469OS-specific backends. 485OS-specific backends (I vastly prefer correctness over speed hacks).
470 486
471This backend maps C<EV_READ> and C<EV_WRITE> in the same way as 487This backend maps C<EV_READ> and C<EV_WRITE> in the same way as
472C<EVBACKEND_POLL>. 488C<EVBACKEND_POLL>.
473 489
474=item C<EVBACKEND_ALL> 490=item C<EVBACKEND_ALL>
… …
527responsibility to either stop all watchers cleanly yourself I<before> 543responsibility to either stop all watchers cleanly yourself I<before>
528calling this function, or cope with the fact afterwards (which is usually 544calling this function, or cope with the fact afterwards (which is usually
529the easiest thing, you can just ignore the watchers and/or C<free ()> them 545the easiest thing, you can just ignore the watchers and/or C<free ()> them
530for example). 546for example).
531 547
532Note that certain global state, such as signal state, will not be freed by 548Note that certain global state, such as signal state (and installed signal
533this function, and related watchers (such as signal and child watchers) 549handlers), will not be freed by this function, and related watchers (such
534would need to be stopped manually. 550as signal and child watchers) would need to be stopped manually.
535 551
536In general it is not advisable to call this function except in the 552In general it is not advisable to call this function except in the
537rare occasion where you really need to free e.g. the signal handling 553rare occasion where you really need to free e.g. the signal handling
538pipe fds. If you need dynamically allocated loops it is better to use 554pipe fds. If you need dynamically allocated loops it is better to use
539C<ev_loop_new> and C<ev_loop_destroy>). 555C<ev_loop_new> and C<ev_loop_destroy>).
… …
631the loop. 647the loop.
632 648
633A flags value of C<EVLOOP_ONESHOT> will look for new events (waiting if 649A flags value of C<EVLOOP_ONESHOT> will look for new events (waiting if
634necessary) and will handle those and any already outstanding ones. It 650necessary) and will handle those and any already outstanding ones. It
635will block your process until at least one new event arrives (which could 651will block your process until at least one new event arrives (which could
636be an event internal to libev itself, so there is no guarentee that a 652be an event internal to libev itself, so there is no guarantee that a
637user-registered callback will be called), and will return after one 653user-registered callback will be called), and will return after one
638iteration of the loop. 654iteration of the loop.
639 655
640This is useful if you are waiting for some external event in conjunction 656This is useful if you are waiting for some external event in conjunction
641with something not expressible using other libev watchers (i.e. "roll your 657with something not expressible using other libev watchers (i.e. "roll your
… …
768they fire on, say, one-second boundaries only. 784they fire on, say, one-second boundaries only.
769 785
770=item ev_loop_verify (loop) 786=item ev_loop_verify (loop)
771 787
772This function only does something when C<EV_VERIFY> support has been 788This function only does something when C<EV_VERIFY> support has been
773compiled in. which is the default for non-minimal builds. It tries to go 789compiled in, which is the default for non-minimal builds. It tries to go
774through all internal structures and checks them for validity. If anything 790through all internal structures and checks them for validity. If anything
775is found to be inconsistent, it will print an error message to standard 791is found to be inconsistent, it will print an error message to standard
776error and call C<abort ()>. 792error and call C<abort ()>.
777 793
778This can be used to catch bugs inside libev itself: under normal 794This can be used to catch bugs inside libev itself: under normal
… …
781 797
782=back 798=back
783 799
784 800
785=head1 ANATOMY OF A WATCHER 801=head1 ANATOMY OF A WATCHER
802
803In the following description, uppercase C<TYPE> in names stands for the
804watcher type, e.g. C<ev_TYPE_start> can mean C<ev_timer_start> for timer
805watchers and C<ev_io_start> for I/O watchers.
786 806
787A watcher is a structure that you create and register to record your 807A watcher is a structure that you create and register to record your
788interest in some event. For instance, if you want to wait for STDIN to 808interest in some event. For instance, if you want to wait for STDIN to
789become readable, you would create an C<ev_io> watcher for that: 809become readable, you would create an C<ev_io> watcher for that:
790 810
… …
793 ev_io_stop (w); 813 ev_io_stop (w);
794 ev_unloop (loop, EVUNLOOP_ALL); 814 ev_unloop (loop, EVUNLOOP_ALL);
795 } 815 }
796 816
797 struct ev_loop *loop = ev_default_loop (0); 817 struct ev_loop *loop = ev_default_loop (0);
818
798 ev_io stdin_watcher; 819 ev_io stdin_watcher;
820
799 ev_init (&stdin_watcher, my_cb); 821 ev_init (&stdin_watcher, my_cb);
800 ev_io_set (&stdin_watcher, STDIN_FILENO, EV_READ); 822 ev_io_set (&stdin_watcher, STDIN_FILENO, EV_READ);
801 ev_io_start (loop, &stdin_watcher); 823 ev_io_start (loop, &stdin_watcher);
824
802 ev_loop (loop, 0); 825 ev_loop (loop, 0);
803 826
804As you can see, you are responsible for allocating the memory for your 827As you can see, you are responsible for allocating the memory for your
805watcher structures (and it is usually a bad idea to do this on the stack, 828watcher structures (and it is I<usually> a bad idea to do this on the
806although this can sometimes be quite valid). 829stack).
830
831Each watcher has an associated watcher structure (called C<struct ev_TYPE>
832or simply C<ev_TYPE>, as typedefs are provided for all watcher structs).
807 833
808Each watcher structure must be initialised by a call to C<ev_init 834Each watcher structure must be initialised by a call to C<ev_init
809(watcher *, callback)>, which expects a callback to be provided. This 835(watcher *, callback)>, which expects a callback to be provided. This
810callback gets invoked each time the event occurs (or, in the case of I/O 836callback gets invoked each time the event occurs (or, in the case of I/O
811watchers, each time the event loop detects that the file descriptor given 837watchers, each time the event loop detects that the file descriptor given
812is readable and/or writable). 838is readable and/or writable).
813 839
814Each watcher type has its own C<< ev_<type>_set (watcher *, ...) >> macro 840Each watcher type further has its own C<< ev_TYPE_set (watcher *, ...) >>
815with arguments specific to this watcher type. There is also a macro 841macro to configure it, with arguments specific to the watcher type. There
816to combine initialisation and setting in one call: C<< ev_<type>_init 842is also a macro to combine initialisation and setting in one call: C<<
817(watcher *, callback, ...) >>. 843ev_TYPE_init (watcher *, callback, ...) >>.
818 844
819To make the watcher actually watch out for events, you have to start it 845To make the watcher actually watch out for events, you have to start it
820with a watcher-specific start function (C<< ev_<type>_start (loop, watcher 846with a watcher-specific start function (C<< ev_TYPE_start (loop, watcher
821*) >>), and you can stop watching for events at any time by calling the 847*) >>), and you can stop watching for events at any time by calling the
822corresponding stop function (C<< ev_<type>_stop (loop, watcher *) >>. 848corresponding stop function (C<< ev_TYPE_stop (loop, watcher *) >>.
823 849
824As long as your watcher is active (has been started but not stopped) you 850As long as your watcher is active (has been started but not stopped) you
825must not touch the values stored in it. Most specifically you must never 851must not touch the values stored in it. Most specifically you must never
826reinitialise it or call its C<set> macro. 852reinitialise it or call its C<ev_TYPE_set> macro.
827 853
828Each and every callback receives the event loop pointer as first, the 854Each and every callback receives the event loop pointer as first, the
829registered watcher structure as second, and a bitset of received events as 855registered watcher structure as second, and a bitset of received events as
830third argument. 856third argument.
831 857
… …
912 938
913=back 939=back
914 940
915=head2 GENERIC WATCHER FUNCTIONS 941=head2 GENERIC WATCHER FUNCTIONS
916 942
917In the following description, C<TYPE> stands for the watcher type,
918e.g. C<timer> for C<ev_timer> watchers and C<io> for C<ev_io> watchers.
919
920=over 4 943=over 4
921 944
922=item C<ev_init> (ev_TYPE *watcher, callback) 945=item C<ev_init> (ev_TYPE *watcher, callback)
923 946
924This macro initialises the generic portion of a watcher. The contents 947This macro initialises the generic portion of a watcher. The contents
… …
1032The default priority used by watchers when no priority has been set is 1055The default priority used by watchers when no priority has been set is
1033always C<0>, which is supposed to not be too high and not be too low :). 1056always C<0>, which is supposed to not be too high and not be too low :).
1034 1057
1035Setting a priority outside the range of C<EV_MINPRI> to C<EV_MAXPRI> is 1058Setting a priority outside the range of C<EV_MINPRI> to C<EV_MAXPRI> is
1036fine, as long as you do not mind that the priority value you query might 1059fine, as long as you do not mind that the priority value you query might
1037or might not have been adjusted to be within valid range. 1060or might not have been clamped to the valid range.
1038 1061
1039=item ev_invoke (loop, ev_TYPE *watcher, int revents) 1062=item ev_invoke (loop, ev_TYPE *watcher, int revents)
1040 1063
1041Invoke the C<watcher> with the given C<loop> and C<revents>. Neither 1064Invoke the C<watcher> with the given C<loop> and C<revents>. Neither
1042C<loop> nor C<revents> need to be valid as long as the watcher callback 1065C<loop> nor C<revents> need to be valid as long as the watcher callback
… …
1426 1449
1427Changing the timeout is trivial as well (if it isn't hard-coded in the 1450Changing the timeout is trivial as well (if it isn't hard-coded in the
1428callback :) - just change the timeout and invoke the callback, which will 1451callback :) - just change the timeout and invoke the callback, which will
1429fix things for you. 1452fix things for you.
1430 1453
1431=item 4. Whee, use a double-linked list for your timeouts. 1454=item 4. Wee, just use a double-linked list for your timeouts.
1432 1455
1433If there is not one request, but many thousands, all employing some kind 1456If there is not one request, but many thousands (millions...), all
1434of timeout with the same timeout value, then one can do even better: 1457employing some kind of timeout with the same timeout value, then one can
1458do even better:
1435 1459
1436When starting the timeout, calculate the timeout value and put the timeout 1460When starting the timeout, calculate the timeout value and put the timeout
1437at the I<end> of the list. 1461at the I<end> of the list.
1438 1462
1439Then use an C<ev_timer> to fire when the timeout at the I<beginning> of 1463Then use an C<ev_timer> to fire when the timeout at the I<beginning> of
… …
1448complication, and having to use a constant timeout. The constant timeout 1472complication, and having to use a constant timeout. The constant timeout
1449ensures that the list stays sorted. 1473ensures that the list stays sorted.
1450 1474
1451=back 1475=back
1452 1476
1453So what method is the best? 1477So which method the best?
1454 1478
1455The method #2 is a simple no-brain-required solution that is adequate in 1479Method #2 is a simple no-brain-required solution that is adequate in most
1456most situations. Method #3 requires a bit more thinking, but handles many 1480situations. Method #3 requires a bit more thinking, but handles many cases
1457cases better, and isn't very complicated either. In most case, choosing 1481better, and isn't very complicated either. In most case, choosing either
1458either one is fine. 1482one is fine, with #3 being better in typical situations.
1459 1483
1460Method #1 is almost always a bad idea, and buys you nothing. Method #4 is 1484Method #1 is almost always a bad idea, and buys you nothing. Method #4 is
1461rather complicated, but extremely efficient, something that really pays 1485rather complicated, but extremely efficient, something that really pays
1462off after the first or so million of active timers, i.e. it's usually 1486off after the first million or so of active timers, i.e. it's usually
1463overkill :) 1487overkill :)
1464 1488
1465=head3 The special problem of time updates 1489=head3 The special problem of time updates
1466 1490
1467Establishing the current time is a costly operation (it usually takes at 1491Establishing the current time is a costly operation (it usually takes at
… …
1898 1922
1899 1923
1900=head2 C<ev_stat> - did the file attributes just change? 1924=head2 C<ev_stat> - did the file attributes just change?
1901 1925
1902This watches a file system path for attribute changes. That is, it calls 1926This watches a file system path for attribute changes. That is, it calls
1903C<stat> regularly (or when the OS says it changed) and sees if it changed 1927C<stat> on that path in regular intervals (or when the OS says it changed)
1904compared to the last time, invoking the callback if it did. 1928and sees if it changed compared to the last time, invoking the callback if
1929it did.
1905 1930
1906The path does not need to exist: changing from "path exists" to "path does 1931The path does not need to exist: changing from "path exists" to "path does
1907not exist" is a status change like any other. The condition "path does 1932not exist" is a status change like any other. The condition "path does
1908not exist" is signified by the C<st_nlink> field being zero (which is 1933not exist" is signified by the C<st_nlink> field being zero (which is
1909otherwise always forced to be at least one) and all the other fields of 1934otherwise always forced to be at least one) and all the other fields of
1910the stat buffer having unspecified contents. 1935the stat buffer having unspecified contents.
1911 1936
1912The path I<should> be absolute and I<must not> end in a slash. If it is 1937The path I<must not> end in a slash or contain special components such as
1938C<.> or C<..>. The path I<should> be absolute: If it is relative and
1913relative and your working directory changes, the behaviour is undefined. 1939your working directory changes, then the behaviour is undefined.
1914 1940
1915Since there is no standard kernel interface to do this, the portable 1941Since there is no portable change notification interface available, the
1916implementation simply calls C<stat (2)> regularly on the path to see if 1942portable implementation simply calls C<stat(2)> regularly on the path
1917it changed somehow. You can specify a recommended polling interval for 1943to see if it changed somehow. You can specify a recommended polling
1918this case. If you specify a polling interval of C<0> (highly recommended!) 1944interval for this case. If you specify a polling interval of C<0> (highly
1919then a I<suitable, unspecified default> value will be used (which 1945recommended!) then a I<suitable, unspecified default> value will be used
1920you can expect to be around five seconds, although this might change 1946(which you can expect to be around five seconds, although this might
1921dynamically). Libev will also impose a minimum interval which is currently 1947change dynamically). Libev will also impose a minimum interval which is
1922around C<0.1>, but thats usually overkill. 1948currently around C<0.1>, but that's usually overkill.
1923 1949
1924This watcher type is not meant for massive numbers of stat watchers, 1950This watcher type is not meant for massive numbers of stat watchers,
1925as even with OS-supported change notifications, this can be 1951as even with OS-supported change notifications, this can be
1926resource-intensive. 1952resource-intensive.
1927 1953
… …
1937support disabled by default, you get the 32 bit version of the stat 1963support disabled by default, you get the 32 bit version of the stat
1938structure. When using the library from programs that change the ABI to 1964structure. When using the library from programs that change the ABI to
1939use 64 bit file offsets the programs will fail. In that case you have to 1965use 64 bit file offsets the programs will fail. In that case you have to
1940compile libev with the same flags to get binary compatibility. This is 1966compile libev with the same flags to get binary compatibility. This is
1941obviously the case with any flags that change the ABI, but the problem is 1967obviously the case with any flags that change the ABI, but the problem is
1942most noticeably disabled with ev_stat and large file support. 1968most noticeably displayed with ev_stat and large file support.
1943 1969
1944The solution for this is to lobby your distribution maker to make large 1970The solution for this is to lobby your distribution maker to make large
1945file interfaces available by default (as e.g. FreeBSD does) and not 1971file interfaces available by default (as e.g. FreeBSD does) and not
1946optional. Libev cannot simply switch on large file support because it has 1972optional. Libev cannot simply switch on large file support because it has
1947to exchange stat structures with application programs compiled using the 1973to exchange stat structures with application programs compiled using the
… …
1966descriptor open on the object at all times, and detecting renames, unlinks 1992descriptor open on the object at all times, and detecting renames, unlinks
1967etc. is difficult. 1993etc. is difficult.
1968 1994
1969=head3 The special problem of stat time resolution 1995=head3 The special problem of stat time resolution
1970 1996
1971The C<stat ()> system call only supports full-second resolution portably, and 1997The C<stat ()> system call only supports full-second resolution portably,
1972even on systems where the resolution is higher, most file systems still 1998and even on systems where the resolution is higher, most file systems
1973only support whole seconds. 1999still only support whole seconds.
1974 2000
1975That means that, if the time is the only thing that changes, you can 2001That means that, if the time is the only thing that changes, you can
1976easily miss updates: on the first update, C<ev_stat> detects a change and 2002easily miss updates: on the first update, C<ev_stat> detects a change and
1977calls your callback, which does something. When there is another update 2003calls your callback, which does something. When there is another update
1978within the same second, C<ev_stat> will be unable to detect unless the 2004within the same second, C<ev_stat> will be unable to detect unless the
… …
2617=over 4 2643=over 4
2618 2644
2619=item ev_async_init (ev_async *, callback) 2645=item ev_async_init (ev_async *, callback)
2620 2646
2621Initialises and configures the async watcher - it has no parameters of any 2647Initialises and configures the async watcher - it has no parameters of any
2622kind. There is a C<ev_asynd_set> macro, but using it is utterly pointless, 2648kind. There is a C<ev_async_set> macro, but using it is utterly pointless,
2623trust me. 2649trust me.
2624 2650
2625=item ev_async_send (loop, ev_async *) 2651=item ev_async_send (loop, ev_async *)
2626 2652
2627Sends/signals/activates the given C<ev_async> watcher, that is, feeds 2653Sends/signals/activates the given C<ev_async> watcher, that is, feeds
… …
2946=item D 2972=item D
2947 2973
2948Leandro Lucarella has written a D language binding (F<ev.d>) for libev, to 2974Leandro Lucarella has written a D language binding (F<ev.d>) for libev, to
2949be found at L<http://proj.llucax.com.ar/wiki/evd>. 2975be found at L<http://proj.llucax.com.ar/wiki/evd>.
2950 2976
2977=item Ocaml
2978
2979Erkki Seppala has written Ocaml bindings for libev, to be found at
2980L<http://modeemi.cs.tut.fi/~flux/software/ocaml-ev/>.
2981
2951=back 2982=back
2952 2983
2953 2984
2954=head1 MACRO MAGIC 2985=head1 MACRO MAGIC
2955 2986
… …
3055 3086
3056 #define EV_STANDALONE 1 3087 #define EV_STANDALONE 1
3057 #include "ev.h" 3088 #include "ev.h"
3058 3089
3059Both header files and implementation files can be compiled with a C++ 3090Both header files and implementation files can be compiled with a C++
3060compiler (at least, thats a stated goal, and breakage will be treated 3091compiler (at least, that's a stated goal, and breakage will be treated
3061as a bug). 3092as a bug).
3062 3093
3063You need the following files in your source tree, or in a directory 3094You need the following files in your source tree, or in a directory
3064in your include path (e.g. in libev/ when using -Ilibev): 3095in your include path (e.g. in libev/ when using -Ilibev):
3065 3096
… …
3537loop, as long as you don't confuse yourself). The only exception is that 3568loop, as long as you don't confuse yourself). The only exception is that
3538you must not do this from C<ev_periodic> reschedule callbacks. 3569you must not do this from C<ev_periodic> reschedule callbacks.
3539 3570
3540Care has been taken to ensure that libev does not keep local state inside 3571Care has been taken to ensure that libev does not keep local state inside
3541C<ev_loop>, and other calls do not usually allow for coroutine switches as 3572C<ev_loop>, and other calls do not usually allow for coroutine switches as
3542they do not clal any callbacks. 3573they do not call any callbacks.
3543 3574
3544=head2 COMPILER WARNINGS 3575=head2 COMPILER WARNINGS
3545 3576
3546Depending on your compiler and compiler settings, you might get no or a 3577Depending on your compiler and compiler settings, you might get no or a
3547lot of warnings when compiling libev code. Some people are apparently 3578lot of warnings when compiling libev code. Some people are apparently
… …
3581 ==2274== definitely lost: 0 bytes in 0 blocks. 3612 ==2274== definitely lost: 0 bytes in 0 blocks.
3582 ==2274== possibly lost: 0 bytes in 0 blocks. 3613 ==2274== possibly lost: 0 bytes in 0 blocks.
3583 ==2274== still reachable: 256 bytes in 1 blocks. 3614 ==2274== still reachable: 256 bytes in 1 blocks.
3584 3615
3585Then there is no memory leak, just as memory accounted to global variables 3616Then there is no memory leak, just as memory accounted to global variables
3586is not a memleak - the memory is still being refernced, and didn't leak. 3617is not a memleak - the memory is still being referenced, and didn't leak.
3587 3618
3588Similarly, under some circumstances, valgrind might report kernel bugs 3619Similarly, under some circumstances, valgrind might report kernel bugs
3589as if it were a bug in libev (e.g. in realloc or in the poll backend, 3620as if it were a bug in libev (e.g. in realloc or in the poll backend,
3590although an acceptable workaround has been found here), or it might be 3621although an acceptable workaround has been found here), or it might be
3591confused. 3622confused.

Diff Legend

– Removed lines
+ Added lines
< Changed lines
> Changed lines