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

Comparing libev/ev.pod (file contents):
Revision 1.329 by root, Sun Oct 24 20:16:00 2010 UTC vs.
Revision 1.334 by root, Mon Oct 25 10:30:23 2010 UTC

… …
77on event-based programming, nor will it introduce event-based programming 77on event-based programming, nor will it introduce event-based programming
78with libev. 78with libev.
79 79
80Familiarity with event based programming techniques in general is assumed 80Familiarity with event based programming techniques in general is assumed
81throughout this document. 81throughout this document.
82
83=head1 WHAT TO READ WHEN IN A HURRY
84
85This manual tries to be very detailed, but unfortunately, this also makes
86it very long. If you just want to know the basics of libev, I suggest
87reading L<ANATOMY OF A WATCHER>, then the L<EXAMPLE PROGRAM> above and
88look up the missing functions in L<GLOBAL FUNCTIONS> and the C<ev_io> and
89C<ev_timer> sections in L<WATCHER TYPES>.
82 90
83=head1 ABOUT LIBEV 91=head1 ABOUT LIBEV
84 92
85Libev is an event loop: you register interest in certain events (such as a 93Libev is an event loop: you register interest in certain events (such as a
86file descriptor being readable or a timeout occurring), and it will manage 94file descriptor being readable or a timeout occurring), and it will manage
… …
300An event loop is described by a C<struct ev_loop *> (the C<struct> is 308An event loop is described by a C<struct ev_loop *> (the C<struct> is
301I<not> optional in this case unless libev 3 compatibility is disabled, as 309I<not> optional in this case unless libev 3 compatibility is disabled, as
302libev 3 had an C<ev_loop> function colliding with the struct name). 310libev 3 had an C<ev_loop> function colliding with the struct name).
303 311
304The library knows two types of such loops, the I<default> loop, which 312The library knows two types of such loops, the I<default> loop, which
305supports signals and child events, and dynamically created event loops 313supports child process events, and dynamically created event loops which
306which do not. 314do not.
307 315
308=over 4 316=over 4
309 317
310=item struct ev_loop *ev_default_loop (unsigned int flags) 318=item struct ev_loop *ev_default_loop (unsigned int flags)
311 319
… …
1114The event loop has been resumed in the child process after fork (see 1122The event loop has been resumed in the child process after fork (see
1115C<ev_fork>). 1123C<ev_fork>).
1116 1124
1117=item C<EV_CLEANUP> 1125=item C<EV_CLEANUP>
1118 1126
1119The event loop is abotu to be destroyed (see C<ev_cleanup>). 1127The event loop is about to be destroyed (see C<ev_cleanup>).
1120 1128
1121=item C<EV_ASYNC> 1129=item C<EV_ASYNC>
1122 1130
1123The given async watcher has been asynchronously notified (see C<ev_async>). 1131The given async watcher has been asynchronously notified (see C<ev_async>).
1124 1132
… …
4757structure (guaranteed by POSIX but not by ISO C for example), but it also 4765structure (guaranteed by POSIX but not by ISO C for example), but it also
4758assumes that the same (machine) code can be used to call any watcher 4766assumes that the same (machine) code can be used to call any watcher
4759callback: The watcher callbacks have different type signatures, but libev 4767callback: The watcher callbacks have different type signatures, but libev
4760calls them using an C<ev_watcher *> internally. 4768calls them using an C<ev_watcher *> internally.
4761 4769
4770=item pointer accesses must be thread-atomic
4771
4772Accessing a pointer value must be atomic, it must both be readable and
4773writable in one piece - this is the case on all current architectures.
4774
4762=item C<sig_atomic_t volatile> must be thread-atomic as well 4775=item C<sig_atomic_t volatile> must be thread-atomic as well
4763 4776
4764The type C<sig_atomic_t volatile> (or whatever is defined as 4777The type C<sig_atomic_t volatile> (or whatever is defined as
4765C<EV_ATOMIC_T>) must be atomic with respect to accesses from different 4778C<EV_ATOMIC_T>) must be atomic with respect to accesses from different
4766threads. This is not part of the specification for C<sig_atomic_t>, but is 4779threads. This is not part of the specification for C<sig_atomic_t>, but is
… …
4872=back 4885=back
4873 4886
4874 4887
4875=head1 PORTING FROM LIBEV 3.X TO 4.X 4888=head1 PORTING FROM LIBEV 3.X TO 4.X
4876 4889
4877The major version 4 introduced some minor incompatible changes to the API. 4890The major version 4 introduced some incompatible changes to the API.
4878 4891
4879At the moment, the C<ev.h> header file tries to implement superficial 4892At the moment, the C<ev.h> header file provides compatibility definitions
4880compatibility, so most programs should still compile. Those might be 4893for all changes, so most programs should still compile. The compatibility
4881removed in later versions of libev, so better update early than late. 4894layer might be removed in later versions of libev, so better update to the
4895new API early than late.
4882 4896
4883=over 4 4897=over 4
4898
4899=item C<EV_COMPAT3> backwards compatibility mechanism
4900
4901The backward compatibility mechanism can be controlled by
4902C<EV_COMPAT3>. See L<PREPROCESSOR SYMBOLS/MACROS> in the L<EMBEDDING>
4903section.
4884 4904
4885=item C<ev_default_destroy> and C<ev_default_fork> have been removed 4905=item C<ev_default_destroy> and C<ev_default_fork> have been removed
4886 4906
4887These calls can be replaced easily by their C<ev_loop_xxx> counterparts: 4907These calls can be replaced easily by their C<ev_loop_xxx> counterparts:
4888 4908
… …
4914ev_loop> anymore and C<EV_TIMER> now follows the same naming scheme 4934ev_loop> anymore and C<EV_TIMER> now follows the same naming scheme
4915as all other watcher types. Note that C<ev_loop_fork> is still called 4935as all other watcher types. Note that C<ev_loop_fork> is still called
4916C<ev_loop_fork> because it would otherwise clash with the C<ev_fork> 4936C<ev_loop_fork> because it would otherwise clash with the C<ev_fork>
4917typedef. 4937typedef.
4918 4938
4919=item C<EV_COMPAT3> backwards compatibility mechanism
4920
4921The backward compatibility mechanism can be controlled by
4922C<EV_COMPAT3>. See L<PREPROCESSOR SYMBOLS/MACROS> in the L<EMBEDDING>
4923section.
4924
4925=item C<EV_MINIMAL> mechanism replaced by C<EV_FEATURES> 4939=item C<EV_MINIMAL> mechanism replaced by C<EV_FEATURES>
4926 4940
4927The preprocessor symbol C<EV_MINIMAL> has been replaced by a different 4941The preprocessor symbol C<EV_MINIMAL> has been replaced by a different
4928mechanism, C<EV_FEATURES>. Programs using C<EV_MINIMAL> usually compile 4942mechanism, C<EV_FEATURES>. Programs using C<EV_MINIMAL> usually compile
4929and work, but the library code will of course be larger. 4943and work, but the library code will of course be larger.
… …
5003 5017
5004=back 5018=back
5005 5019
5006=head1 AUTHOR 5020=head1 AUTHOR
5007 5021
5008Marc Lehmann <libev@schmorp.de>, with repeated corrections by Mikael Magnusson. 5022Marc Lehmann <libev@schmorp.de>, with repeated corrections by Mikael
5023Magnusson and Emanuele Giaquinta.
5009 5024

Diff Legend

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