FDs opened by kqueue does not support polling

[trungnt2910]

FDs opened by kqueue(), or the underlying _kern_event_queue_create() system call, does not support being polled.

The ​underlying implementation is not providing callbacks for the fd_select and fd_deselect operations, which, along with calls to notify_select_events() or similar, are required for poll() to work on the FD.

This deviates from the ​documented behavior of kqueue() on FreeBSD, which does allow poll() and select() on the returned FD.

Furthermore, supporting this would allow wrapping native Haiku objects (ports, sems, teams, and the like) into an FD that can be polled by the shared code of ported applications.

[waddlesplash]

Turning random objects into an FD that can be polled is Linux-style behavior. We already support processes in our kqueue.

I would support being able to open ports as FDs to read/write them, this would also pave the way for improving the security of ports by eventually allowing only FD read/write to (remote/non-owned) ports instead of directly operating on them, which would solve some problems here.

Allowing kqueue to be polled/selected would mean allowing the kqueue to be added to another kqueue. I don't think that's a good idea (we'd have to add more logic to prevent recursion, which wouldn't be simple), and I don't really see any significant usecases for this.