API for using poll/epoll instead of select
keithp at keithp.com
Thu May 26 19:09:14 UTC 2016
Adam Jackson <ajax at nwnk.net> writes:
> Exposing edge/level in ospoll_add is a bit funky, you're silently
> degrading edge to level if the OS backend can't do edge. kqueue could do
> it if the code were written, and I suspect win32's WaitForMultipleObjects
> could be made to do it if we got really wild, but Solaris doesn't have an
> edge-triggered API for this at all (does have port_create which is
> basically level-triggered epoll, but).
Good comment here. poll(2) doesn't have edge-triggered options either,
so the ospoll code emulates that by remembering the previous value and
not reporting when it hasn't changed. This requires a call to
ospoll_reset_events in io.c to clear the previous value when input runs
> If the intent is that asking for edge is an indication that the caller
> _can_ use edge-triggers but will work with either then I guess that's
> fine. A comment to that effect would be good.
Could do it this way as well, and would eliminate the
ospoll_reset_events interface. The only cost would be extra calls to the
callback for clients which have input and are not getting serviced,
which is not a big deal as that doesn't actually happen all that often
in normal X usage.
dix handles this just fine; checking to see if the client is on the
ready list before inserting it.
Sounds like a good change to me as it will simplify the poll(2)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 810 bytes
Desc: not available
More information about the xorg-devel