I'm working on a DevTools Protocol client, that can be used to automate certain web browsers (similar to Puppeteer for node.js).
Basically, there is a WebSocket to which commands can be sent, and through which return values of these commands and events will be sent back.
One WebSocket can have many sessions (for example, one session per tab), which is the reason why I think async would be ideal for this use-case.
I'd prefer to use threads, but this seems difficult to archive. Basically, I need a dispatcher thread that waits for incoming WebSocket messages, at the same time sends WebSocket messages to the server and also waits for incoming messages via a Crossbeam channel. It seems an asynchronous approach would make this easier.
Because I anyway planned to test the performance of an async-based client, I thought I would go ahead and start with that.
Thanks, for the hint! I wasn't aware of that. This makes the situation even worst, in my opinion...
What would be the best way to recognize crates that seem executor agnostic, but depend on a specific executor? See if there is a non-optional dependency to a runtime?
It seems, Tokio is used and recommended the most, and I wouldn't be completely against using it exclusively (however, from what I have read, I'd prefer async-std, personally).
Maybe it would be a good approach to start with Tokio, and later – when compatibility between runtimes hopefully has improved – to update the API to be executor agnostic.
That being said, what do you think about using Smol to run other runtimes?
For example, there is this example that demonstrates how to use smol with async-std, tokio, surf, and reqwest:
https://github.com/stjepang/smol/blob/master/examples/other-runtimes.rs
After thinking about it... am I correct in thinking that with Smol and Tokio there would be two runtimes running at the same time?
I assumed first, Smol would somehow switch Tokio to use Smol, and there therefore would be only one event loop and so on.
Is that incorrect?