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