selectors: Plumb in kqueue user events instead of pipes for custom events #19587
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This enables using kQueue EVFILT_USER for much faster user triggered events on MacOSX and likely *BSDs. Currently gated behind a new kqueue flag
-d:kqueueUserEvent
.It's a little tricky to make it so the
trigger
function works on a kqueue custom event. I handled this by only enabling triggering once a custom event has been registered with a selector and is given that selector's kqueue FD. This may cause a bit of a race condition when closing that selector, though similar issues occur with pipe based events as well.There's a bit of a question I had about whether a
SelectEvent
should support being added to multiple selectors. The current implementation only allows a user event to be registered with a single selector. On LinuxSelectEvent
's useeventfd
and should work fine with multiple selectors & threads. Given that, it might be best to enable the kqueue-based user events to be registered with multiple selectors. That'd require using a sharedArray of kqueue FD's.