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.168 by root, Mon Jun 9 14:31:36 2008 UTC

… …
2626libev. EV is developed together with libev. Apart from the EV core module, 2626libev. EV is developed together with libev. Apart from the EV core module,
2627there are additional modules that implement libev-compatible interfaces 2627there are additional modules that implement libev-compatible interfaces
2628to C<libadns> (C<EV::ADNS>), C<Net::SNMP> (C<Net::SNMP::EV>) and the 2628to 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>). 2629C<libglib> event core (C<Glib::EV> and C<EV::Glib>).
2630 2630
2631It can be found and installed via CPAN, its homepage is found at 2631It can be found and installed via CPAN, its homepage is at
2632L<http://software.schmorp.de/pkg/EV>. 2632L<http://software.schmorp.de/pkg/EV>.
2633
2634=item Python
2635
2636Python bindings can be found at L<http://code.google.com/p/pyev/>. It
2637seems to be quite complete and well-documented. Note, however, that the
2638patch they require for libev is outright dangerous as it breaks the ABI
2639for everybody else, and therefore, should never be applied in an installed
2640libev (if python requires an incompatible ABI then it needs to embed
2641libev).
2633 2642
2634=item Ruby 2643=item Ruby
2635 2644
2636Tony Arcieri has written a ruby extension that offers access to a subset 2645Tony Arcieri has written a ruby extension that offers access to a subset
2637of the libev API and adds file handle abstractions, asynchronous DNS and 2646of 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 3326more than a hundred or so sockets, then likely it needs to use a totally
3318different implementation for windows, as libev offers the POSIX readiness 3327different implementation for windows, as libev offers the POSIX readiness
3319notification model, which cannot be implemented efficiently on windows 3328notification model, which cannot be implemented efficiently on windows
3320(Microsoft monopoly games). 3329(Microsoft monopoly games).
3321 3330
3331A typical way to use libev under windows is to embed it (see the embedding
3332section for details) and use the following F<evwrap.h> header file instead
3333of F<ev.h>:
3334
3335 #define EV_STANDALONE /* keeps ev from requiring config.h */
3336 #define EV_SELECT_IS_WINSOCKET 1 /* configure libev for windows select */
3337
3338 #include "ev.h"
3339
3340And compile the following F<evwrap.c> file into your project (make sure
3341you do I<not> compile the F<ev.c> or any other embedded soruce files!):
3342
3343 #include "evwrap.h"
3344 #include "ev.c"
3345
3322=over 4 3346=over 4
3323 3347
3324=item The winsocket select function 3348=item The winsocket select function
3325 3349
3326The winsocket C<select> function doesn't follow POSIX in that it 3350The winsocket C<select> function doesn't follow POSIX in that it
3327requires socket I<handles> and not socket I<file descriptors> (it is 3351requires socket I<handles> and not socket I<file descriptors> (it is
3328also extremely buggy). This makes select very inefficient, and also 3352also extremely buggy). This makes select very inefficient, and also
3329requires a mapping from file descriptors to socket handles. See the 3353requires a mapping from file descriptors to socket handles (the Microsoft
3354C 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 3355discussion 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. 3356C<EV_FD_TO_WIN32_HANDLE> preprocessor symbols for more info.
3332 3357
3333The configuration for a "naked" win32 using the Microsoft runtime 3358The configuration for a "naked" win32 using the Microsoft runtime
3334libraries and raw winsocket select is: 3359libraries and raw winsocket select is:
… …
3374In addition to a working ISO-C implementation, libev relies on a few 3399In addition to a working ISO-C implementation, libev relies on a few
3375additional extensions: 3400additional extensions:
3376 3401
3377=over 4 3402=over 4
3378 3403
3404=item C<void (*)(ev_watcher_type *, int revents)> must have compatible
3405calling conventions regardless of C<ev_watcher_type *>.
3406
3407Libev assumes not only that all watcher pointers have the same internal
3408structure (guaranteed by POSIX but not by ISO C for example), but it also
3409assumes that the same (machine) code can be used to call any watcher
3410callback: The watcher callbacks have different type signatures, but libev
3411calls them using an C<ev_watcher *> internally.
3412
3379=item C<sig_atomic_t volatile> must be thread-atomic as well 3413=item C<sig_atomic_t volatile> must be thread-atomic as well
3380 3414
3381The type C<sig_atomic_t volatile> (or whatever is defined as 3415The type C<sig_atomic_t volatile> (or whatever is defined as
3382C<EV_ATOMIC_T>) must be atomic w.r.t. accesses from different 3416C<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 3417threads. This is not part of the specification for C<sig_atomic_t>, but is

Diff Legend

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