I'm raising this because #26 and #214 take care nicely of the primary use case for async using uv_queue_work but there is another scenario that would be good to support long term IMO.
The uv_queue_work method caters for a long running Javascript method returning immediately and then invoking a callback sometime later. This is good for a lot of cases. It uses the node thread pool.
However our scenario is that we invoke a Javascript method which should then create a new Rust thread, rather than use the node thread pool. This thread runs potentially forever but needs to communicate back to Javascript via the node event loop. This is what uv_async_send is designed for (with a caveat -- multiple calls to uv_async_send may be coalesced).
It would be great to have this supported at some point.
I'm raising this because #26 and #214 take care nicely of the primary use case for async using
uv_queue_workbut there is another scenario that would be good to support long term IMO.The
uv_queue_workmethod caters for a long running Javascript method returning immediately and then invoking a callback sometime later. This is good for a lot of cases. It uses the node thread pool.However our scenario is that we invoke a Javascript method which should then create a new Rust thread, rather than use the node thread pool. This thread runs potentially forever but needs to communicate back to Javascript via the node event loop. This is what
uv_async_sendis designed for (with a caveat -- multiple calls touv_async_sendmay be coalesced).It would be great to have this supported at some point.