Open lights0123 opened 4 years ago
It might be better to make a separate library that uses async/await. The "thread for everything" approach is what is done in the official ROS clients. Working with async/await forces things into a single thread to process IO bound actions.
The library was created before futures were a thing, so even things that would be better with green threads are using OS threads. In those areas I'd say that switching to an async/await solution would be an advantage for sure. A good example would be the XMLRPC server and client each node exposes to communicate with roscore.
Let me start with this: I'm happy to write all this myself, but I'd like to know if this would be accepted upstream (and thus I should keep it as API-compatible as possible) or not.
I'd like there to be an efficient (roslibjs is pretty good for JS, but it's not efficient at all),
async
/await
-first ROS library in any language really, but I think Rust is the best bet for that. I want to be able to handle service requests, asynchronous messages, etc. all without spawning a bunch of threads, and use all the cool stuff possible with it likeselect!
ing between the first available message efficiently.There's two ways I could go about doing this:
async
, and expose existing APIs as simpleblock_on
wrappersI would certainly lean towards the second option, as there would only be one backend to maintain. Some executors (like
smol
) are very small, so they wouldn't increase the binary by much (only a few KBs) and could possibly speed up even existing blocking APIs.