-
Notifications
You must be signed in to change notification settings - Fork 27
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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Event Loop #12
Comments
I'd be interested in diving into this one - I'd definitely need more guidance, and will probably have to do a good chunk of research in order to complete it. I found this project, which looks like it might be relevant for I/O (unless you want to stick to libuv bindings): https://github.com/tokio-rs/mio |
I wouldn't be disappointed if we used mio. |
Thinking about this more, we should use something that has support for io_uring |
It would be interesting to see if this can be abstracted enough so that a "bring your own event loop" solution can happen for lib usage. Or at least "bring your own futures executor". A big 馃憤 on |
That sounds pretty cool to me - in a sense, make the event loop "pluggable"?
Sounds like we like It seems like we want to support a pluggable event loop such that:
To that end, we could define our event loop abstraction as a What do y'all think? Does that make sense? |
One thing to take into account is that the IO library won't necessarily be the only thing driving the event loop. Timers would be one example of this. |
Ah - so maybe the proper pluggable abstraction in my description above is the io library, rather than the event loop? Does that make more sense? |
@solumos the non-io stuff wouldn't be pluggable, i was just pointing out that the io library itself can't be the driver of the event loop, because there are other pieces. |
The approach I had in mind was to to have a pluggable exectutor. That is, FWIW, I took a quick look, and it looks like this is exactly how Deno works. |
This seems potentially useful (not a shameless plug, I swear!) https://github.com/DataDog/scipio |
As a quick update given this has been sitting for a while - it's been really interesting digging into this, but due to some unforeseen personal circumstances, I won't be able to devote as much time to this issue (as well as the project at-large) as I'd hoped. If anyone else would like to pick this up, please feel free! I do think the "pluggable Futures executor" is a really interesting concept for jstime, and it's been fun exploring. It seems to me the first step would be implementing the event loop with a pluggable futures executor, while also focusing on a single implementation to "plug in" as the default executor (plenty of options to choose from!) |
I might want to dig into this, so some thoughts: |
I think we need to hold off on exploring the event loop until we can fix TLA support and get the V8 update unblocked |
AFAIAW, v8 has an abstraction of Platform, where you can plugin you event loop implementation, for example, node.js uses libuv, chrome uses libevent. |
Probably need one of those 馃槄
The text was updated successfully, but these errors were encountered: