Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kqueue event loop (*BSD, macOS) #14829

Closed

Conversation

ysbaddaden
Copy link
Contributor

@ysbaddaden ysbaddaden commented Jul 23, 2024

Why settle with epoll (linux specific) when we can have epoll+kqueue and support all the implemented POSIX targets (albeit we should use event ports on Solaris)?

Extracts the generic parts of Crystal::Epoll::EventLoop into the Crystal::Evented namespace. Only the event (de)registration into epoll/kqueue and the actual run loops are specific (+ how to interrupt + timeout precision).

May have the same issue as the epoll event loop, with CI sometimes failing with a pthread_mutex_unlock in Crystal::Evented::EventLoop#enqueue or #dequeue failing with EPERM. I reproduced on FreeBSD but I can't anymore with the latest patches.

Another shared issue is with preview_mt: we call Crystal::Scheduler.enqueue which may be reentrant (fiber channel uses a PIPE).

Tested on FreeBSD 14. CI says Darwin is working.

Supersedes (or follow up) #14814.

We can't call EPOLL_CTL_MOD with EPOLLEXCLUSIVE. Let's disable it for
now and see later if we can replace it with a pair of EPOLL_CTL_DEL and
EPOLL_CTL_ADD.
Process.run sometimes hang forever after fork and before exec, because
it tries to close a fd that requires to lock, but another thread may
have already acquired the lock, while `fork` only duplicates the current
thread (the other ones are not, and the forked process was left waiting
for a mutex to be unlocked, which would never happen.
That required to allocate a Node for the interrupt event, which ain't a
bad idea.
Extracts the generic parts of the event loop into an intermediary class
between Crystal::EventLoop and Crystal::Epoll::EventLoop so we can reuse
it to implement the event loop on other similar syscalls (poll, kqueue).
Sometimes we only want a pair of fds, and not IO::FileDescriptor
objects.
For some reason specs fail with a fiber failing to raise an exception
because `pthread_mutex_unlock` failed with EPERM while trying to dequeue
the `Fiber#resume_event` from the event loop.

Re-creating the thread mutex after fork seems to fix the issue.
@ysbaddaden ysbaddaden self-assigned this Jul 23, 2024
@straight-shoota
Copy link
Member

Superseded by #14959

@ysbaddaden ysbaddaden deleted the feature/kqueue-event-loop branch September 13, 2024 13:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants