… | |
… | |
305 | |
305 | |
306 | This function can be used to "simulate" a signal receive. It is completely |
306 | This function can be used to "simulate" a signal receive. It is completely |
307 | safe to call this function at any time, from any context, including signal |
307 | safe to call this function at any time, from any context, including signal |
308 | handlers or random threads. |
308 | handlers or random threads. |
309 | |
309 | |
310 | It's main use is to customise signal handling in your process, especially |
310 | Its main use is to customise signal handling in your process, especially |
311 | in the presence of threads. For example, you could block signals |
311 | in the presence of threads. For example, you could block signals |
312 | by default in all threads (and specifying C<EVFLAG_NOSIGMASK> when |
312 | by default in all threads (and specifying C<EVFLAG_NOSIGMASK> when |
313 | creating any loops), and in one thread, use C<sigwait> or any other |
313 | creating any loops), and in one thread, use C<sigwait> or any other |
314 | mechanism to wait for signals, then "deliver" them to libev by calling |
314 | mechanism to wait for signals, then "deliver" them to libev by calling |
315 | C<ev_feed_signal>. |
315 | C<ev_feed_signal>. |
… | |
… | |
582 | =item C<EVBACKEND_PORT> (value 32, Solaris 10) |
582 | =item C<EVBACKEND_PORT> (value 32, Solaris 10) |
583 | |
583 | |
584 | This uses the Solaris 10 event port mechanism. As with everything on Solaris, |
584 | This uses the Solaris 10 event port mechanism. As with everything on Solaris, |
585 | it's really slow, but it still scales very well (O(active_fds)). |
585 | it's really slow, but it still scales very well (O(active_fds)). |
586 | |
586 | |
587 | Please note that Solaris event ports can deliver a lot of spurious |
|
|
588 | notifications, so you need to use non-blocking I/O or other means to avoid |
|
|
589 | blocking when no data (or space) is available. |
|
|
590 | |
|
|
591 | While this backend scales well, it requires one system call per active |
587 | While this backend scales well, it requires one system call per active |
592 | file descriptor per loop iteration. For small and medium numbers of file |
588 | file descriptor per loop iteration. For small and medium numbers of file |
593 | descriptors a "slow" C<EVBACKEND_SELECT> or C<EVBACKEND_POLL> backend |
589 | descriptors a "slow" C<EVBACKEND_SELECT> or C<EVBACKEND_POLL> backend |
594 | might perform better. |
590 | might perform better. |
595 | |
591 | |
596 | On the positive side, with the exception of the spurious readiness |
592 | On the positive side, this backend actually performed fully to |
597 | notifications, this backend actually performed fully to specification |
|
|
598 | in all tests and is fully embeddable, which is a rare feat among the |
593 | specification in all tests and is fully embeddable, which is a rare feat |
599 | OS-specific backends (I vastly prefer correctness over speed hacks). |
594 | among the OS-specific backends (I vastly prefer correctness over speed |
|
|
595 | hacks). |
|
|
596 | |
|
|
597 | On the negative side, the interface is I<bizarre> - so bizarre that |
|
|
598 | even sun itself gets it wrong in their code examples: The event polling |
|
|
599 | function sometimes returning events to the caller even though an error |
|
|
600 | occured, but with no indication whether it has done so or not (yes, it's |
|
|
601 | even documented that way) - deadly for edge-triggered interfaces where |
|
|
602 | you absolutely have to know whether an event occured or not because you |
|
|
603 | have to re-arm the watcher. |
|
|
604 | |
|
|
605 | Fortunately libev seems to be able to work around these idiocies. |
600 | |
606 | |
601 | This backend maps C<EV_READ> and C<EV_WRITE> in the same way as |
607 | This backend maps C<EV_READ> and C<EV_WRITE> in the same way as |
602 | C<EVBACKEND_POLL>. |
608 | C<EVBACKEND_POLL>. |
603 | |
609 | |
604 | =item C<EVBACKEND_ALL> |
610 | =item C<EVBACKEND_ALL> |