… | |
… | |
300 | An event loop is described by a C<struct ev_loop *> (the C<struct> is |
300 | An event loop is described by a C<struct ev_loop *> (the C<struct> is |
301 | I<not> optional in this case unless libev 3 compatibility is disabled, as |
301 | I<not> optional in this case unless libev 3 compatibility is disabled, as |
302 | libev 3 had an C<ev_loop> function colliding with the struct name). |
302 | libev 3 had an C<ev_loop> function colliding with the struct name). |
303 | |
303 | |
304 | The library knows two types of such loops, the I<default> loop, which |
304 | The library knows two types of such loops, the I<default> loop, which |
305 | supports signals and child events, and dynamically created event loops |
305 | supports child process events, and dynamically created event loops which |
306 | which do not. |
306 | do not. |
307 | |
307 | |
308 | =over 4 |
308 | =over 4 |
309 | |
309 | |
310 | =item struct ev_loop *ev_default_loop (unsigned int flags) |
310 | =item struct ev_loop *ev_default_loop (unsigned int flags) |
311 | |
311 | |
… | |
… | |
1114 | The event loop has been resumed in the child process after fork (see |
1114 | The event loop has been resumed in the child process after fork (see |
1115 | C<ev_fork>). |
1115 | C<ev_fork>). |
1116 | |
1116 | |
1117 | =item C<EV_CLEANUP> |
1117 | =item C<EV_CLEANUP> |
1118 | |
1118 | |
1119 | The event loop is abotu to be destroyed (see C<ev_cleanup>). |
1119 | The event loop is about to be destroyed (see C<ev_cleanup>). |
1120 | |
1120 | |
1121 | =item C<EV_ASYNC> |
1121 | =item C<EV_ASYNC> |
1122 | |
1122 | |
1123 | The given async watcher has been asynchronously notified (see C<ev_async>). |
1123 | The given async watcher has been asynchronously notified (see C<ev_async>). |
1124 | |
1124 | |
… | |
… | |
3098 | |
3098 | |
3099 | =item ev_fork_init (ev_fork *, callback) |
3099 | =item ev_fork_init (ev_fork *, callback) |
3100 | |
3100 | |
3101 | Initialises and configures the fork watcher - it has no parameters of any |
3101 | Initialises and configures the fork watcher - it has no parameters of any |
3102 | kind. There is a C<ev_fork_set> macro, but using it is utterly pointless, |
3102 | kind. There is a C<ev_fork_set> macro, but using it is utterly pointless, |
3103 | believe me. |
3103 | really. |
3104 | |
3104 | |
3105 | =back |
3105 | =back |
3106 | |
3106 | |
3107 | |
3107 | |
3108 | =head2 C<ev_cleanup> - even the best things end |
3108 | =head2 C<ev_cleanup> - even the best things end |
… | |
… | |
3126 | |
3126 | |
3127 | =item ev_cleanup_init (ev_cleanup *, callback) |
3127 | =item ev_cleanup_init (ev_cleanup *, callback) |
3128 | |
3128 | |
3129 | Initialises and configures the cleanup watcher - it has no parameters of |
3129 | Initialises and configures the cleanup watcher - it has no parameters of |
3130 | any kind. There is a C<ev_cleanup_set> macro, but using it is utterly |
3130 | any kind. There is a C<ev_cleanup_set> macro, but using it is utterly |
3131 | pointless, believe me. |
3131 | pointless, I assure you. |
3132 | |
3132 | |
3133 | =back |
3133 | =back |
3134 | |
3134 | |
3135 | Example: Register an atexit handler to destroy the default loop, so any |
3135 | Example: Register an atexit handler to destroy the default loop, so any |
3136 | cleanup functions are called. |
3136 | cleanup functions are called. |
… | |
… | |
4757 | structure (guaranteed by POSIX but not by ISO C for example), but it also |
4757 | structure (guaranteed by POSIX but not by ISO C for example), but it also |
4758 | assumes that the same (machine) code can be used to call any watcher |
4758 | assumes that the same (machine) code can be used to call any watcher |
4759 | callback: The watcher callbacks have different type signatures, but libev |
4759 | callback: The watcher callbacks have different type signatures, but libev |
4760 | calls them using an C<ev_watcher *> internally. |
4760 | calls them using an C<ev_watcher *> internally. |
4761 | |
4761 | |
|
|
4762 | =item pointer accesses must be thread-atomic |
|
|
4763 | |
|
|
4764 | Accessing a pointer value must be atomic, it must both be readable and |
|
|
4765 | writable in one piece - this is the case on all current architectures. |
|
|
4766 | |
4762 | =item C<sig_atomic_t volatile> must be thread-atomic as well |
4767 | =item C<sig_atomic_t volatile> must be thread-atomic as well |
4763 | |
4768 | |
4764 | The type C<sig_atomic_t volatile> (or whatever is defined as |
4769 | The type C<sig_atomic_t volatile> (or whatever is defined as |
4765 | C<EV_ATOMIC_T>) must be atomic with respect to accesses from different |
4770 | C<EV_ATOMIC_T>) must be atomic with respect to accesses from different |
4766 | threads. This is not part of the specification for C<sig_atomic_t>, but is |
4771 | threads. This is not part of the specification for C<sig_atomic_t>, but is |
… | |
… | |
4872 | =back |
4877 | =back |
4873 | |
4878 | |
4874 | |
4879 | |
4875 | =head1 PORTING FROM LIBEV 3.X TO 4.X |
4880 | =head1 PORTING FROM LIBEV 3.X TO 4.X |
4876 | |
4881 | |
4877 | The major version 4 introduced some minor incompatible changes to the API. |
4882 | The major version 4 introduced some incompatible changes to the API. |
4878 | |
4883 | |
4879 | At the moment, the C<ev.h> header file tries to implement superficial |
4884 | At the moment, the C<ev.h> header file provides compatibility definitions |
4880 | compatibility, so most programs should still compile. Those might be |
4885 | for all changes, so most programs should still compile. The compatibility |
4881 | removed in later versions of libev, so better update early than late. |
4886 | layer might be removed in later versions of libev, so better update to the |
|
|
4887 | new API early than late. |
4882 | |
4888 | |
4883 | =over 4 |
4889 | =over 4 |
|
|
4890 | |
|
|
4891 | =item C<EV_COMPAT3> backwards compatibility mechanism |
|
|
4892 | |
|
|
4893 | The backward compatibility mechanism can be controlled by |
|
|
4894 | C<EV_COMPAT3>. See L<PREPROCESSOR SYMBOLS/MACROS> in the L<EMBEDDING> |
|
|
4895 | section. |
4884 | |
4896 | |
4885 | =item C<ev_default_destroy> and C<ev_default_fork> have been removed |
4897 | =item C<ev_default_destroy> and C<ev_default_fork> have been removed |
4886 | |
4898 | |
4887 | These calls can be replaced easily by their C<ev_loop_xxx> counterparts: |
4899 | These calls can be replaced easily by their C<ev_loop_xxx> counterparts: |
4888 | |
4900 | |
… | |
… | |
4914 | ev_loop> anymore and C<EV_TIMER> now follows the same naming scheme |
4926 | ev_loop> anymore and C<EV_TIMER> now follows the same naming scheme |
4915 | as all other watcher types. Note that C<ev_loop_fork> is still called |
4927 | as all other watcher types. Note that C<ev_loop_fork> is still called |
4916 | C<ev_loop_fork> because it would otherwise clash with the C<ev_fork> |
4928 | C<ev_loop_fork> because it would otherwise clash with the C<ev_fork> |
4917 | typedef. |
4929 | typedef. |
4918 | |
4930 | |
4919 | =item C<EV_COMPAT3> backwards compatibility mechanism |
|
|
4920 | |
|
|
4921 | The backward compatibility mechanism can be controlled by |
|
|
4922 | C<EV_COMPAT3>. See L<PREPROCESSOR SYMBOLS/MACROS> in the L<EMBEDDING> |
|
|
4923 | section. |
|
|
4924 | |
|
|
4925 | =item C<EV_MINIMAL> mechanism replaced by C<EV_FEATURES> |
4931 | =item C<EV_MINIMAL> mechanism replaced by C<EV_FEATURES> |
4926 | |
4932 | |
4927 | The preprocessor symbol C<EV_MINIMAL> has been replaced by a different |
4933 | The preprocessor symbol C<EV_MINIMAL> has been replaced by a different |
4928 | mechanism, C<EV_FEATURES>. Programs using C<EV_MINIMAL> usually compile |
4934 | mechanism, C<EV_FEATURES>. Programs using C<EV_MINIMAL> usually compile |
4929 | and work, but the library code will of course be larger. |
4935 | and work, but the library code will of course be larger. |
… | |
… | |
5003 | |
5009 | |
5004 | =back |
5010 | =back |
5005 | |
5011 | |
5006 | =head1 AUTHOR |
5012 | =head1 AUTHOR |
5007 | |
5013 | |
5008 | Marc Lehmann <libev@schmorp.de>, with repeated corrections by Mikael Magnusson. |
5014 | Marc Lehmann <libev@schmorp.de>, with repeated corrections by Mikael |
|
|
5015 | Magnusson and Emanuele Giaquinta. |
5009 | |
5016 | |