… | |
… | |
77 | on event-based programming, nor will it introduce event-based programming |
77 | on event-based programming, nor will it introduce event-based programming |
78 | with libev. |
78 | with libev. |
79 | |
79 | |
80 | Familiarity with event based programming techniques in general is assumed |
80 | Familiarity with event based programming techniques in general is assumed |
81 | throughout this document. |
81 | throughout this document. |
|
|
82 | |
|
|
83 | =head1 WHAT TO READ WHEN IN A HURRY |
|
|
84 | |
|
|
85 | This manual tries to be very detailed, but unfortunately, this also makes |
|
|
86 | it very long. If you just want to know the basics of libev, I suggest |
|
|
87 | reading L<ANATOMY OF A WATCHER>, then the L<EXAMPLE PROGRAM> above and |
|
|
88 | look up the missing functions in L<GLOBAL FUNCTIONS> and the C<ev_io> and |
|
|
89 | C<ev_timer> sections in L<WATCHER TYPES>. |
82 | |
90 | |
83 | =head1 ABOUT LIBEV |
91 | =head1 ABOUT LIBEV |
84 | |
92 | |
85 | Libev is an event loop: you register interest in certain events (such as a |
93 | Libev is an event loop: you register interest in certain events (such as a |
86 | file descriptor being readable or a timeout occurring), and it will manage |
94 | file descriptor being readable or a timeout occurring), and it will manage |
… | |
… | |
4757 | structure (guaranteed by POSIX but not by ISO C for example), but it also |
4765 | 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 |
4766 | assumes that the same (machine) code can be used to call any watcher |
4759 | callback: The watcher callbacks have different type signatures, but libev |
4767 | callback: The watcher callbacks have different type signatures, but libev |
4760 | calls them using an C<ev_watcher *> internally. |
4768 | calls them using an C<ev_watcher *> internally. |
4761 | |
4769 | |
|
|
4770 | =item pointer accesses must be thread-atomic |
|
|
4771 | |
|
|
4772 | Accessing a pointer value must be atomic, it must both be readable and |
|
|
4773 | writable 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 | |
4764 | The type C<sig_atomic_t volatile> (or whatever is defined as |
4777 | 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 |
4778 | 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 |
4779 | threads. This is not part of the specification for C<sig_atomic_t>, but is |
… | |
… | |
5004 | |
5017 | |
5005 | =back |
5018 | =back |
5006 | |
5019 | |
5007 | =head1 AUTHOR |
5020 | =head1 AUTHOR |
5008 | |
5021 | |
5009 | Marc Lehmann <libev@schmorp.de>, with repeated corrections by Mikael Magnusson. |
5022 | Marc Lehmann <libev@schmorp.de>, with repeated corrections by Mikael |
|
|
5023 | Magnusson and Emanuele Giaquinta. |
5010 | |
5024 | |