> Or B) I strip out the long-running threads and just make this an abstraction > over status/nim-taskpools that can be used for all kinds of tasks including > IO, given that they can send a message back when they're done, which is read > from by the main-thread controlling the taskpool. For IO it would be mostly > sync-IO that blocks that particular worker-thread until it is done. That > would be stripping it down to a pure "Executor-Design" according to the > blogpost.
I would say this is more similar to an actor model. For example in Rust land, actix builds on top of the Tokio threadpool. The API is pretty simple: <https://actix.rs/docs/actix/actor/> Otherwise Pony-lang is a good inspiration and the actor part is simple C: <https://github.com/ponylang/ponyc/blob/main/src/libponyrt/actor/actor.c> Re: studying I wish you luck. Before creating Weave I did 2 other threadpools (can be seen in Weave commit history), but I went from the start with the idea that I'm just exploring the field and will likely throwaway everything. You can see in 0.1 of Weave that I looked deeply into 2 other schedulers and reimplemented some until I know enough whether that direction is promising or not: <https://github.com/mratsim/weave/tree/v0.1.0/experiments>
