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

RFC 2: Skeleton for ExecutionContext #15350

Open
wants to merge 10 commits into
base: master
Choose a base branch
from

Conversation

ysbaddaden
Copy link
Contributor

Integrates the skeleton as per RFC #0002.

  • Add the ExecutionContext module;
  • Add the ExecutionContext::Scheduler module;
  • Add the execution_context compile-time flag.

When the execution_context flag is set:

  • Don't load Crystal::Scheduler;
  • Plug ExecutionContext instead of Crystal::Scheduler in spawn, Fiber, ...

This is only the skeleton: there are no implementations (yet). Trying to compile anything with -Dexecution_context will obviously fail until the follow up pull requests implementing at least the ST and/or MT context are merged.

refs #15342

- Add the `ExecutionContext` module;
- Add the `ExecutionContext::Scheduler` module;
- Add the `execution_context` compile-time flag.

When the `execution_context` flag is set:

- Don't load `Crystal::Scheduler`;
- Plug `ExecutionContext` instead of `Crystal::Scheduler` in `spawn`,
  `Fiber`, ...

This is only the skeleton: there are no implementations (yet). Trying to
compile anything with `-Dexecution_context` will obviously fail for the
time being.
The current ST and MT schedulers use a distinct pool per thread, which
means we only need the thread safety for execution contexts that will
share a single pool for a whole context.
The point is to avoid parallel enqueues while running the event loop, so
we get better control to where and how the runnable fibers are enqueued;
for example all at once instead of one by one (may not be as effective
as it sounds).

More importantly for Execution Contexts: it avoids parallel enqueues
while the eventloop is running which sometimes leads to confusing
behavior; for example when deciding to wake up a scheduler/thread we
musn't interryupt the event loop (obviously).

This is working correctly for the Polling (Epoll, Kqueue) and IOCP event
loop implementations. I'm less confident with the libevent one where the
external library executes arbitrary callbacks.
src/concurrent.cr Outdated Show resolved Hide resolved
src/crystal/system/unix/signal.cr Outdated Show resolved Hide resolved
src/crystal/system/thread.cr Outdated Show resolved Hide resolved
src/execution_context/execution_context.cr Outdated Show resolved Hide resolved
src/execution_context/scheduler.cr Outdated Show resolved Hide resolved
ysbaddaden and others added 3 commits January 17, 2025 14:09
Co-authored-by: Johannes Müller <straightshoota@gmail.com>
We need this because we don't load crystal/scheduler anymore when
execution contexts are enabled.
src/execution_context/scheduler.cr Outdated Show resolved Hide resolved
src/execution_context/scheduler.cr Outdated Show resolved Hide resolved
@ysbaddaden ysbaddaden mentioned this pull request Jan 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Review
Development

Successfully merging this pull request may close these issues.

3 participants