Currently, the timeout operation is implemented by racing given operation with a sleeping thread (BTW a similar approach is used in Cats Effect).
I was wondering if we could leverage a ScheduledExecutorService instead. It operates on a single threaded, which schedules and starts actual tasks. Netty uses this mechanism for timeouts in its IdleStateHandler. A scheduled task starts, emits an event and ends immediately. Then, Netty's internals handle the event in order to abort communication if a timeout occured.
In case of Ox, a scheduled task would start on a virtual thread (see hints in this Stack Overflow discussion). It would then call cancelation of the fork that's wrapped with timeout.
I don't know if such a solution will be more performant than racing with a sleeping thread, but I'm leaving this idea here for consideration. One certain issue is that the single-threaded pool for scheduling doesn't sound like something we want to create for each scope, but rather like a "runtime" that needs passing around.
Currently, the
timeoutoperation is implemented by racing given operation with a sleeping thread (BTW a similar approach is used in Cats Effect).I was wondering if we could leverage a
ScheduledExecutorServiceinstead. It operates on a single threaded, which schedules and starts actual tasks. Netty uses this mechanism for timeouts in its IdleStateHandler. A scheduled task starts, emits an event and ends immediately. Then, Netty's internals handle the event in order to abort communication if a timeout occured.In case of Ox, a scheduled task would start on a virtual thread (see hints in this Stack Overflow discussion). It would then call cancelation of the fork that's wrapped with timeout.
I don't know if such a solution will be more performant than racing with a sleeping thread, but I'm leaving this idea here for consideration. One certain issue is that the single-threaded pool for scheduling doesn't sound like something we want to create for each scope, but rather like a "runtime" that needs passing around.