-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
ysbaddaden
wants to merge
29
commits into
crystal-lang:master
from
ysbaddaden:feature/kqueue-event-loop
Closed
Kqueue event loop (*BSD, macOS) #14829
ysbaddaden
wants to merge
29
commits into
crystal-lang:master
from
ysbaddaden:feature/kqueue-event-loop
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
This was referenced Jul 26, 2024
Superseded by #14959 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
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 theCrystal::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
inCrystal::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 callCrystal::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.