API for using poll/epoll instead of select

[Keith Packard]

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
dry.

> 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)
interface.

-- 
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20160526/953f50d2/attachment-0001.sig>