Event Loop about jstime

[devsnek]

I wouldn't be disappointed if we used mio.

[solumos]

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

[MylesBorins]

@solumos I think that this will depend heavily on the type of system access we want to provide. @devsnek and I had talked about about maybe using libuv / uvwasi, although I am definitely flexible.

[devsnek]

Thinking about this more, we should use something that has support for io_uring

[bengl]

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 io_uring in general though. https://crates.io/crates/rio

[solumos]

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".

That sounds pretty cool to me - in a sense, make the event loop "pluggable"?

we should use something that has support for io_uring

A big 👍 on io_uring in general though. https://crates.io/crates/rio

Sounds like we like io_uring? Here's some relevant discussion in mio + libuv that I looked over for context.

It seems like we want to support a pluggable event loop such that:

1. A cross-platform epoll / kqueue / IOCP abstraction is supported "out-of-the-box" (likely using mio?)
2. A linux-based io_uring abstraction is supported (likely using rio?).
3. Any "bring your own" event loop can be "plugged-in"

To that end, we could define our event loop abstraction as a trait, and provide mio + rio implementations that can be "plugged-in" to the runtime. Any valid implementation of the event loop trait could also be "plugged-in" via "jstime-as-lib".

What do y'all think? Does that make sense?

[devsnek]

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.

[solumos]

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?

[devsnek]

@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.

[bengl]

The approach I had in mind was to to have a pluggable exectutor. That is, jstime should be able to provide a Future that can be used with any executor.

FWIW, I took a quick look, and it looks like this is exactly how Deno works.

[bengl]

This seems potentially useful (not a shameless plug, I swear!) https://github.com/DataDog/scipio

[solumos]

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!)

[assapir]

I might want to dig into this, so some thoughts:
Pluggable: can we do it via a trait, and have one (some? none?) default implementation?

[MylesBorins]

I think we need to hold off on exploring the event loop until we can fix TLA support and get the V8 update unblocked

#106

[wong2]

AFAIAW, v8 has an abstraction of Platform, where you can plugin you event loop implementation, for example, node.js uses libuv, chrome uses libevent.