I tried with uv_queue_work() first. But it didn't seem to match what I needed or maybe I didn't use it correctly (?). What I did: - uv_queue_work(... work_cb, workAfter_cb) - in work_cb() I would call my driver method call_driver(..., driver_cb, baton);
But this wasn't ideal because I would have to block work_cb() until driver_cb() would be called back from the driver. Also, I wasn't quite sure that in driver_cb, I would unlock the right work_cb() method. As far as I understand uv.h, with uv_async_init(), I'm just declaring what to do when uv_async_send() is called. And, since I have a handle, I'm 'sure' I launch the corresponding workAfter() to my driver_cb(). I forgot to mention that there might be many calls to the driver (and it's a hardware driver in its own thread...), which in turns would call the same driver_cb() so it was necessary to map some baton to the JS method. I tried on Mac and Linux and got the same async behavior and the right JS methods being called back with correct timing ;-) ;-) You are right that the hardware task may be long-lived and indeed the driver calls back to report progress or error. So it's pretty similar to having a long-lived CPU thread. However, if I was using a CPU thread, I think uv_queue_work would have been more appropriate. But here, the hardware has its own thread management so it's more like a case of sync'ing between 2 independent thread pools. On Sunday, March 18, 2012 12:56:10 PM UTC-7, Nathan Rajlich wrote: > > 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 >> > >> >> >