You're correct in that uv_queue_work() is the replacement for eio_custom(), so that is ideal for situations where you need to do some long (possibly CPU-bound) task on libuv's thread pool, then firing a single callback on the main thread when that is done.
I may be incorrect, but I was under the impression that @m1k3l was doing something on another thread that is possibly long-lived, or doesn't necessarily finish doing its business before needing to communicate back to the main thread. I think a good use-case for this could be reporting progress events back to the main thread from a thread doing a lot of work that may take a long time. Of course, someone correct me if I have a misunderstanding here :) On Sun, Mar 18, 2012 at 8:50 AM, Micheil Smith <mich...@brandedcode.com>wrote: > @Nathan, you probably know this stuff better than me now days, but > couldn't @m1k3l just use uv_queue_work() to enqueue the call to a > third-party library? > > (mainly due to the fact that uv_queue_work appears to be similar to > eio_custom.) > > – Micheil > > On 16/03/2012, at 9:56 PM, m1k3l wrote: > > > Thanks! I got it to work. Here is what I did, let me know if this > correct. > > > > struct Baton { > > Persistent<Function> callback; > > int error; > > std::string error_message; > > uv_async_t async; > > > > // Custom data > > Persistent<Object> data; > > }; > > > > JS_METHOD(Event::setCallback) { > > Baton *baton=new Baton(); > > > baton->callback=Persistent<Function>::New(Local<Function>::Cast(args[0])); > > > > uv_async_init(uv_default_loop(), &baton->async, After_cb); // tell UV > to call After_cb() async > > > > baton->async.data=baton; > > > > call_driver(..., driver_cb, baton); > > } > > > > > > void driver_cb (int status, void *user_data) > > { > > ... > > uv_async_send(((Baton*) user_data)->async); // wakes up UV to call > After_cb() > > } > > > > void After_cb(uv_async_t *handle, int status) { > > Baton *baton = static_cast<Baton*>(handle->data); > > uv_close((uv_handle_t*) &baton->async,NULL); // necessary otherwise UV > will block > > ... > > baton->callback->Call(v8::Context::GetCurrent()->Global(), 1, argv); // > call the JS callback method as usual > > ... > > baton->callback.Dispose(); // delete the baton > > baton->data.Dispose(); > > delete baton; > > } > > > > > > > > On Friday, March 16, 2012 10:48:42 AM UTC-7, Nathan Rajlich wrote: > > I'm pretty sure this is what uv_async_t, uv_async_send and friends are > for, but somebody correct be if I am wrong. > > > > On Fri, Mar 16, 2012 at 10:22 AM, m1k3l <mikese...@gmail.com> wrote: > > Hi, > > > > I have a native method running in its own thread and calling a callback > to post its status. The callback has some user data that I'd like to post > to JS. > > Since the callback is running in a different thread than v8, I can't use > any v8 method to call a JS callback function. So I wonder if there is a way > to use some persistent objects to do that? > > > > One solution I found is to use queue the native method using libuv. This > way, I can use a busy wait in uv's Work callback method until my native > method's callback is called. Then uv's Work callback proceed and I can use > uv's After callback to call the JS callback method, as usual. > > > > While this seems to work, it still looks like very hack-ish. Is there a > better solution/pattern? > > > > Thanks > > > > > > On Friday, March 16, 2012 10:48:42 AM UTC-7, Nathan Rajlich wrote: > > I'm pretty sure this is what uv_async_t, uv_async_send and friends are > for, but somebody correct be if I am wrong. > > > > On Fri, Mar 16, 2012 at 10:22 AM, m1k3l <mikese...@gmail.com> wrote: > > Hi, > > > > I have a native method running in its own thread and calling a callback > to post its status. The callback has some user data that I'd like to post > to JS. > > Since the callback is running in a different thread than v8, I can't use > any v8 method to call a JS callback function. So I wonder if there is a way > to use some persistent objects to do that? > > > > One solution I found is to use queue the native method using libuv. This > way, I can use a busy wait in uv's Work callback method until my native > method's callback is called. Then uv's Work callback proceed and I can use > uv's After callback to call the JS callback method, as usual. > > > > While this seems to work, it still looks like very hack-ish. Is there a > better solution/pattern? > > > > Thanks > > > >