-
Notifications
You must be signed in to change notification settings - Fork 505
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Worker Creation from Foreign Thread #669
Comments
Starting with your last question, As for a wrapper for worker creation from a foreign thread, all of the advice that I have read so far recommends to use I needed this exact functionality in a project I worked on a few years ago, but back then it only needed to work with node 0.10.x and node 0.12.x, and we were not using I don't think there's anything wrong with the method that you described, although it might be a bit expensive if you need to create and destroy a As for "why nobody else seems to have run into this problem?" ... I find myself asking the same question. I intended on experimenting more with the |
AsyncWorker is useful whenever we want to have an asynchronous call to foreign code and potentially that foreign code can call back into the V8 main thread using AsyncProgressWorker.
However, what if you have a callback from a foreign thread that you don't control? In this case, AsyncWorker cannot be created from within the foreign thread (or it would not be trivial in best case) since you don't have an active V8 isolate. You can create one but anything that you pass to that worker from the main isolate would be useless in the new isolate without heavy amounts of context copying (of which I'm not sure can be done correctly right now). So using a V8 callback from the main isolate is pointless here.
Also, in order to call a V8 callback in the first place, memory must be copied again and sent down the queue again via Send member function. This seems a tad wasteful when I really just want a function to execute in the main thread to begin with.
In the end, I determined I needed a new wrapper to achieve what I wanted and created something for my personal project which basically just creates an uv_async_t. I make a wrapper function where whenever I get the signal from a native thread, it creates a new object with the data provided by the signal and sends it off. It calls an Execute function, which runs in the main thread to which I can call my JS callbacks from, no need for a middle man. The memory is marshaled so the Execute function cleans up its own object at the very last second.
TL;DR I'm curious as to why nobody else seems to have run into this problem and/or if there's a better solution that I'm not seeing. The solution I made seems pretty solid but I'm wondering if it's okay to destroy uv_async_t at the last second like I'm doing since while I don't see anywhere that it does and it seems to work, I'm afraid this may change later on or might be platform specific.
In addition, I tried using uv_queue_work with uv_default_loop but this didn't execute on the main thread. However, uv_async_send does, while also using uv_default_loop. Why is this?
The text was updated successfully, but these errors were encountered: