Hey guys,
I struggle to understand the difference in responsibilities between libraries and binaries (consumers) using the Tokio crate.
At the moment i have a library containing a server-task which has a loop accepting clients. Is it idiomatic to return this future to the consumer so it can decide on reactor and scheduling? I imagine this being explicit as a handle that can be scheduled, and allowing for manipulating server configuration at runtime, request to stop is an example.
For my second question: If i'd like to always spawn handler tasks on a threadpool, how well does this mix with returning a handle (representing the server task) to the consumer?
The threadpool requirement feels like an implementation detail. Are there implementations doing this (combining multiple tokio compatible dependencies into one executable)?
What would be a typical library<->consumer interaction when the library defines and executes the tokio runtime, given the consumer needs the ability to asynchronously execute code while the library runtime is running?
My intuitive response seems to circle back into "let the consumer handle runtime setup".
Turning it around; it seems some published crates allow the consumer pushing tasks into the library for scheduling. For example Hyper: https://github.com/hyperium/hyper/blob/069a32b1acc5ece35643c26cf5d9972dace5481c/examples/multi_server.rs#L18-L33
This approach seems to boil down into defining a runtime module, analogue to tokio::runtime, within my own library. This is the only solution i can think of, are there other possibilities left?