-
Notifications
You must be signed in to change notification settings - Fork 560
Description
Currently the only place you can materialize a PollingSystem
is the work-stealing threadpool. Furthermore, all of our polling interfaces are currently in terms of IO
and to get a hold of one you need an IORuntime
.
Why do we care? Even if we are in IO
on the WSTP, it might have the wrong kind of polling system installed, so we need some kind of fallback. Additionally, FS2 has promised Network
and friends for any Async
effect so we need to consider how to keep supporting that without having to maintain a handful of separate implementations that effectively do the same thing ...
I think these problems are somewhat orthogonal, but I suspect they are best solved jointly. Specifically we need:
-
a way to materialize a polling system on a "selector thread"—some sort of single-threaded event loop that just does I/O polling.
-
a way to use our polling interfaces from a non-
IO
effect
Controversial idea: for (1) just make a WSTP with one thread. For (2) keep using IO
and use a Dispatcher
to implement LiftIO[F]
for arbitrary Async[F]
, similar to what Doobie does. This would work, and is arguably no different than using an NIO2 / Netty selector thread with CompletableFuture
/ ChannelFuture
. Same deal: someone else's event loop with someone else's coroutine.
Follow-up to: