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

make std.event.Loop work with --single-threaded #1908

Open
andrewrk opened this issue Feb 1, 2019 · 0 comments
Open

make std.event.Loop work with --single-threaded #1908

andrewrk opened this issue Feb 1, 2019 · 0 comments
Labels
enhancement Solving this issue will likely involve adding new logic or components to the codebase. standard library This issue involves writing Zig code for the standard library.
Milestone

Comments

@andrewrk
Copy link
Member

andrewrk commented Feb 1, 2019

See #1764 (comment)

On MacOS and FreeBSD it will be worth looking into whether kqueue works with file system operations.

When #1907 is implemented, it could be interesting to explore io_submit on Linux instead of epoll, however even so, we would need another implementation for older linuxes that does not rely on a thread.

This issue could potentially require a proposal to modify the single-threaded flag to work at some kind of scope level. Or it could potentially be resolved by making async file system functions actually be blocking in --single-threaded mode.

@andrewrk andrewrk added the standard library This issue involves writing Zig code for the standard library. label Feb 1, 2019
@andrewrk andrewrk added this to the 0.5.0 milestone Feb 1, 2019
@andrewrk andrewrk added the stage1 The process of building from source via WebAssembly and the C backend. label Feb 1, 2019
andrewrk added a commit that referenced this issue Feb 1, 2019
closes #1764

This adds another boolean to the test matrix; hopefully it does not
inflate the time too much.

std.event.Loop does not work with this option yet. See #1908
@andrewrk andrewrk modified the milestones: 0.5.0, 0.6.0 Sep 20, 2019
@andrewrk andrewrk added enhancement Solving this issue will likely involve adding new logic or components to the codebase. and removed stage1 The process of building from source via WebAssembly and the C backend. labels Mar 4, 2020
@andrewrk andrewrk modified the milestones: 0.6.0, 0.7.0 Mar 4, 2020
@andrewrk andrewrk modified the milestones: 0.7.0, 0.8.0 Oct 10, 2020
@andrewrk andrewrk modified the milestones: 0.8.0, 0.9.0 Nov 6, 2020
@andrewrk andrewrk modified the milestones: 0.9.0, 0.10.0 May 19, 2021
francisbouvier added a commit to lightpanda-io/zig-js-runtime that referenced this issue Jan 12, 2023
*Async JS*

For now only callback style is handled (Promises is planned later).

We use persistent handle on v8 JS callback call after retrieving the
event from the kernel, has the parent JS function is finished and
therefore local handles are already garbage collected by v8.

* Event Loop*

We do not use the event loop provided in Zig stdlib but instead Tigerbeetle
IO (https://github.com/tigerbeetledb/tigerbeetle/tree/main/src/io).
The main reason is to have a strictly single-threaded event loop, see
ziglang/zig#1908.
In addition the desing of Tigerbeetle IO based on io_uring (for Linux,
with wrapper around kqueue for MacOS), seems to be the right direction for IO.

Our loop provides callback style native APIs. Async/await style native
API are not planned until zig self-hosted compiler (stage2) support
concurrent features (see ziglang/zig#6025).

Signed-off-by: Francis Bouvier <francis.bouvier@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Solving this issue will likely involve adding new logic or components to the codebase. standard library This issue involves writing Zig code for the standard library.
Projects
None yet
Development

No branches or pull requests

1 participant