… | |
… | |
592 | On the positive side, this backend actually performed fully to |
592 | On the positive side, this backend actually performed fully to |
593 | specification in all tests and is fully embeddable, which is a rare feat |
593 | specification in all tests and is fully embeddable, which is a rare feat |
594 | among the OS-specific backends (I vastly prefer correctness over speed |
594 | among the OS-specific backends (I vastly prefer correctness over speed |
595 | hacks). |
595 | hacks). |
596 | |
596 | |
597 | On the negative side, the interface is I<bizarre>, with the event polling |
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 |
598 | function sometimes returning events to the caller even though an error |
599 | function sometimes returning events to the caller even though an error |
599 | occured, but with no indication whether it has done so or not (yes, it's |
600 | occured, but with no indication whether it has done so or not (yes, it's |
600 | even documented that way) - deadly for edge-triggered interfaces, but |
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 | |
601 | fortunately libev seems to be able to work around it. |
605 | Fortunately libev seems to be able to work around these idiocies. |
602 | |
606 | |
603 | 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 |
604 | C<EVBACKEND_POLL>. |
608 | C<EVBACKEND_POLL>. |
605 | |
609 | |
606 | =item C<EVBACKEND_ALL> |
610 | =item C<EVBACKEND_ALL> |