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

Integrate with the lifetime Event Loop #34

Draft
wants to merge 11 commits into
base: main
Choose a base branch
from

Conversation

ysbaddaden
Copy link
Owner

No description provided.

@ysbaddaden ysbaddaden added the enhancement New feature or request label Sep 24, 2024
@ysbaddaden ysbaddaden self-assigned this Sep 24, 2024
With one evloop per context, we don't need to remember which scheduler
is waiting on the evloop. We just need to know that one is waiting and
to interrupt the evloop in that case.
We reach that method when we:

1. start a thread;
2. start the main thread run loop fiber;
3. resume the run loop fiber.

In every case the local queue is necessarily empty, otherwise we
wouldn't have resumed the run loop. Any parallel enqueue is coming from
the global queue, which is immediately checked, then it should spin.
Fixes a bunch of issues caused by evloop#run enqueueing fibers while
we're running the evloop, which led to many enqueues for ST that could
be replaced with a single bulk enqueue (simpler, faster) as well as
properly handling trying to wake up a thread for MT (and not try to
interrupt the currently running evloop, or no wakeup because a spinning
thread is running the evloop, ...)
It seems to be creating parallelism issues with the GC instead of fixing
them.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Integrate with Crystal::Evented MT: thread imediately parks itself MT context may eventually stall
1 participant