You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Currently the only place you can materialize a
PollingSystem
is the work-stealing threadpool. Furthermore, all of our polling interfaces are currently in terms ofIO
and to get a hold of one you need anIORuntime
.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 promisedNetwork
and friends for anyAsync
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
effectControversial idea: for (1) just make a WSTP with one thread. For (2) keep using
IO
and use aDispatcher
to implementLiftIO[F]
for arbitraryAsync[F]
, similar to what Doobie does. This would work, and is arguably no different than using an NIO2 / Netty selector thread withCompletableFuture
/ChannelFuture
. Same deal: someone else's event loop with someone else's coroutine.Follow-up to:
The text was updated successfully, but these errors were encountered: