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

Comparing libev/ev.pod (file contents):
Revision 1.164 by root, Sat May 31 23:22:23 2008 UTC vs.
Revision 1.169 by root, Fri Jun 20 23:31:19 2008 UTC

… …
1662will be no polling. 1662will be no polling.
1663 1663
1664=head3 ABI Issues (Largefile Support) 1664=head3 ABI Issues (Largefile Support)
1665 1665
1666Libev by default (unless the user overrides this) uses the default 1666Libev by default (unless the user overrides this) uses the default
1667compilation environment, which means that on systems with optionally 1667compilation environment, which means that on systems with large file
1668disabled large file support, you get the 32 bit version of the stat 1668support disabled by default, you get the 32 bit version of the stat
1669structure. When using the library from programs that change the ABI to 1669structure. When using the library from programs that change the ABI to
1670use 64 bit file offsets the programs will fail. In that case you have to 1670use 64 bit file offsets the programs will fail. In that case you have to
1671compile libev with the same flags to get binary compatibility. This is 1671compile libev with the same flags to get binary compatibility. This is
1672obviously the case with any flags that change the ABI, but the problem is 1672obviously the case with any flags that change the ABI, but the problem is
1673most noticeably with ev_stat and large file support. 1673most noticeably disabled with ev_stat and large file support.
1674
1675The solution for this is to lobby your distribution maker to make large
1676file interfaces available by default (as e.g. FreeBSD does) and not
1677optional. Libev cannot simply switch on large file support because it has
1678to exchange stat structures with application programs compiled using the
1679default compilation environment.
1674 1680
1675=head3 Inotify 1681=head3 Inotify
1676 1682
1677When C<inotify (7)> support has been compiled into libev (generally only 1683When C<inotify (7)> support has been compiled into libev (generally only
1678available on Linux) and present at runtime, it will be used to speed up 1684available on Linux) and present at runtime, it will be used to speed up
… …
2626libev. EV is developed together with libev. Apart from the EV core module, 2632libev. EV is developed together with libev. Apart from the EV core module,
2627there are additional modules that implement libev-compatible interfaces 2633there are additional modules that implement libev-compatible interfaces
2628to C<libadns> (C<EV::ADNS>), C<Net::SNMP> (C<Net::SNMP::EV>) and the 2634to C<libadns> (C<EV::ADNS>), C<Net::SNMP> (C<Net::SNMP::EV>) and the
2629C<libglib> event core (C<Glib::EV> and C<EV::Glib>). 2635C<libglib> event core (C<Glib::EV> and C<EV::Glib>).
2630 2636
2631It can be found and installed via CPAN, its homepage is found at 2637It can be found and installed via CPAN, its homepage is at
2632L<http://software.schmorp.de/pkg/EV>. 2638L<http://software.schmorp.de/pkg/EV>.
2639
2640=item Python
2641
2642Python bindings can be found at L<http://code.google.com/p/pyev/>. It
2643seems to be quite complete and well-documented. Note, however, that the
2644patch they require for libev is outright dangerous as it breaks the ABI
2645for everybody else, and therefore, should never be applied in an installed
2646libev (if python requires an incompatible ABI then it needs to embed
2647libev).
2633 2648
2634=item Ruby 2649=item Ruby
2635 2650
2636Tony Arcieri has written a ruby extension that offers access to a subset 2651Tony Arcieri has written a ruby extension that offers access to a subset
2637of the libev API and adds file handle abstractions, asynchronous DNS and 2652of the libev API and adds file handle abstractions, asynchronous DNS and
… …
3317more than a hundred or so sockets, then likely it needs to use a totally 3332more than a hundred or so sockets, then likely it needs to use a totally
3318different implementation for windows, as libev offers the POSIX readiness 3333different implementation for windows, as libev offers the POSIX readiness
3319notification model, which cannot be implemented efficiently on windows 3334notification model, which cannot be implemented efficiently on windows
3320(Microsoft monopoly games). 3335(Microsoft monopoly games).
3321 3336
3337A typical way to use libev under windows is to embed it (see the embedding
3338section for details) and use the following F<evwrap.h> header file instead
3339of F<ev.h>:
3340
3341 #define EV_STANDALONE /* keeps ev from requiring config.h */
3342 #define EV_SELECT_IS_WINSOCKET 1 /* configure libev for windows select */
3343
3344 #include "ev.h"
3345
3346And compile the following F<evwrap.c> file into your project (make sure
3347you do I<not> compile the F<ev.c> or any other embedded soruce files!):
3348
3349 #include "evwrap.h"
3350 #include "ev.c"
3351
3322=over 4 3352=over 4
3323 3353
3324=item The winsocket select function 3354=item The winsocket select function
3325 3355
3326The winsocket C<select> function doesn't follow POSIX in that it 3356The winsocket C<select> function doesn't follow POSIX in that it
3327requires socket I<handles> and not socket I<file descriptors> (it is 3357requires socket I<handles> and not socket I<file descriptors> (it is
3328also extremely buggy). This makes select very inefficient, and also 3358also extremely buggy). This makes select very inefficient, and also
3329requires a mapping from file descriptors to socket handles. See the 3359requires a mapping from file descriptors to socket handles (the Microsoft
3360C runtime provides the function C<_open_osfhandle> for this). See the
3330discussion of the C<EV_SELECT_USE_FD_SET>, C<EV_SELECT_IS_WINSOCKET> and 3361discussion of the C<EV_SELECT_USE_FD_SET>, C<EV_SELECT_IS_WINSOCKET> and
3331C<EV_FD_TO_WIN32_HANDLE> preprocessor symbols for more info. 3362C<EV_FD_TO_WIN32_HANDLE> preprocessor symbols for more info.
3332 3363
3333The configuration for a "naked" win32 using the Microsoft runtime 3364The configuration for a "naked" win32 using the Microsoft runtime
3334libraries and raw winsocket select is: 3365libraries and raw winsocket select is:
… …
3374In addition to a working ISO-C implementation, libev relies on a few 3405In addition to a working ISO-C implementation, libev relies on a few
3375additional extensions: 3406additional extensions:
3376 3407
3377=over 4 3408=over 4
3378 3409
3410=item C<void (*)(ev_watcher_type *, int revents)> must have compatible
3411calling conventions regardless of C<ev_watcher_type *>.
3412
3413Libev assumes not only that all watcher pointers have the same internal
3414structure (guaranteed by POSIX but not by ISO C for example), but it also
3415assumes that the same (machine) code can be used to call any watcher
3416callback: The watcher callbacks have different type signatures, but libev
3417calls them using an C<ev_watcher *> internally.
3418
3379=item C<sig_atomic_t volatile> must be thread-atomic as well 3419=item C<sig_atomic_t volatile> must be thread-atomic as well
3380 3420
3381The type C<sig_atomic_t volatile> (or whatever is defined as 3421The type C<sig_atomic_t volatile> (or whatever is defined as
3382C<EV_ATOMIC_T>) must be atomic w.r.t. accesses from different 3422C<EV_ATOMIC_T>) must be atomic w.r.t. accesses from different
3383threads. This is not part of the specification for C<sig_atomic_t>, but is 3423threads. This is not part of the specification for C<sig_atomic_t>, but is

Diff Legend

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