Skip to content

Figure out how to use polling systems outside of WSTP and IO #3685

@armanbilge

Description

@armanbilge

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:

  1. a way to materialize a polling system on a "selector thread"—some sort of single-threaded event loop that just does I/O polling.

  2. 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:

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions