Changes between Initial Version and Version 1 of Ticket #16846


Ignore:
Timestamp:
Mar 11, 2021, 9:18:39 PM (3 years ago)
Author:
kallisti5
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #16846

    • Property Summary Better document wait_for_objects API calls, or reimplement? → The future of fd stateful monitoring / eventing in Haiku

  • Ticket #16846 – Description

    initial v1  
    1 The "wait_for_objects" API calls in https://github.com/haiku/haiku/blob/master/headers/os/kernel/OS.h#L634 seem to be a potential stand-in for epoll and kqueue (which the Rust tokio-rs mio developers are asking about)
     1Today Haiku offers a "wait_for_objects" API which is as close as we get to epoll / kqueue which exists on OS X / FreeBSD / Linux.
    22
    3 epoll / kqueue exist on OS X / FreeBSD / Linux (however are not part of the posix standard)
     3Pulkomandy pointed out a great overview here:
     4  https://fosdem.org/2021/schedule/event/file_descriptor_monitoring/
     5
     6And some previous work around event polling here:
     7  https://github.com/hamishm/haiku/tree/eventqueue
    48
    59
    6 We should:
    7 1. Better document wait_for_objects with some hints about it being a epoll/kqueue  alternative
    8 2. Refactor the API and make it more friendly for ports inline with epoll / kqueue?
     10A good model would likely be:
     111. Implement a fairly standard/complete io_uring (fd and sockets)
     122. Add epoll/kqueue compatibility functions which silently leverage io_uring
     133. Drop wait_for_objects or make it official. (only consumer seems to be power daemon https://git.haiku-os.org/haiku/tree/src/servers/power/power_daemon.cpp#n118)