An alternative approach is to hook libuv's underlying calls to the OS, for example kevent. This is what's done for Plask's integration of libuv/node with the Cocoa event loop. It might seem a bit complicated, but it is currently the best way to make sure that libuv's internal state is up to date, at least in the case of embedding Node where you don't control all of the entry points / callbacks.
There are some comments about the approach at the top of the file: https://github.com/deanm/plask/blob/master/main.mm On 11 July 2014 14:19, Thiago Padilha <[email protected]> wrote: >> Basically I would like to be able to block until the next event but don't >> acually do anything with the event (e.g. don't run any callbacks) > > In Neovim we use a separate queue to achieve this effect. Here's a > high-level overview of what happens: > > - uv_run(UV_RUN_{ONCE,NOWAIT}) is called > - Any libuv callback that is invoked pushes event data to an event queue > - After uv_run returns, we check if there are events in the queue, and if so > process them. > > We do this mainly because uv_run doesn't support recursion, but Neovim has a > lot of legacy code that calls input functions recursively. Also, it was the > cleanest way I found to embed libuv event loop into vim's own event loop > > -- > You received this message because you are subscribed to the Google Groups > "libuv" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/libuv. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
