… | |
… | |
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 |
… | |
… | |
3374 | In addition to a working ISO-C implementation, libev relies on a few |
3383 | In addition to a working ISO-C implementation, libev relies on a few |
3375 | additional extensions: |
3384 | additional extensions: |
3376 | |
3385 | |
3377 | =over 4 |
3386 | =over 4 |
3378 | |
3387 | |
|
|
3388 | =item C<void (*)(ev_watcher_type *, int revents)> must have compatible |
|
|
3389 | calling conventions regardless of C<ev_watcher_type *>. |
|
|
3390 | |
|
|
3391 | Libev assumes not only that all watcher pointers have the same internal |
|
|
3392 | structure (guaranteed by POSIX but not by ISO C for example), but it also |
|
|
3393 | assumes that the same (machine) code can be used to call any watcher |
|
|
3394 | callback: The watcher callbacks have different type signatures, but libev |
|
|
3395 | calls them using an C<ev_watcher *> internally. |
|
|
3396 | |
3379 | =item C<sig_atomic_t volatile> must be thread-atomic as well |
3397 | =item C<sig_atomic_t volatile> must be thread-atomic as well |
3380 | |
3398 | |
3381 | The type C<sig_atomic_t volatile> (or whatever is defined as |
3399 | 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 |
3400 | 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 |
3401 | threads. This is not part of the specification for C<sig_atomic_t>, but is |