Yes, it is very platform specific, in this case it relies on OSX's ability to call select() on a kqueue file descriptor. Although in my experience when you get to working with UI loops it will always be very platform specific, the mechanisms are very different. I've implemented more or less the same approach for OSX, Windows, and Linux/XWindows. X is much simpler since the connection is just a socket and can be integrated into the libuv event loop. Windows requires a more involved approach, since unlike OSX and kqueue, an IOCP handle is not waitable. Additionally you cannot peek the IOCP queue, if you wait on it an event will be dequeued, so you have to have a helper thread and message the event to the UI thread. I discussed this with a friend at Microsoft on the NT kernel team, and we unfortunately couldn't come up with a good single threaded approach. However, the multi-threaded approach worked well and I didn't seem to notice the messaging overhead for my use.
On 19 July 2014 11:32, Saúl Ibarra Corretgé <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/18/2014 11:15 PM, Dean wrote: >> 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 >> > > The problem with that approach is that its portability is quite > limited. It's the only way (uv_backend_fd) to do things these days > though, but it only works on systems with epoll or kqueue, IIRC. > > I'll read the reference, thanks! > >> 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. >> > > > - -- > Saúl Ibarra Corretgé > bettercallsaghul.com > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > Comment: Using GnuPG with Icedove - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJTyjsUAAoJEEEOVVOum8BZTiQQAIrX3KugoSqxIeizYNhBH7km > U5ev6W0L82VNWu3HnlGdJ4DfwD6pwWTCzAWmgsIFusxtOlK3VVCRgapbS4fpG6Rq > 5N6TVuv6szRz6CahW6vfFiydthvbhLlPD2LJ34o58LVy6Xz2eN9zZ4tbGUWsHBSA > CFiLlbWlxb2LDH1OynIq3UaYP0ecD/phazgMqcuiPGiNaj70oPzMZG73vjpcN4q7 > vORsvp8vNwTCJne4iQhXzMLOxY7/pqtJw5kNh3CyEtTZi84THjjPszG0Fsk/grO6 > /bqncKZQkq7F/dVjtWmiLw+HPOqbhZeFiaPHU1oyqDZB7r8PR309MCVWS2e75ufq > lTML5WdbJm4GhLppnGpXoj++JUXHgciES+c6tghbew+i/i7kUm/ci/THrnG4U4HM > K1uoTIcH0pCZANpkKQaD4mmqZse7CokLPWjGEKmkYa7JllYUxkNpVfODUCKumZ77 > DnAsBJlQ9B5F8UbH9w7GwKsyrdnrRpekcsdEeICL2VE6eqMca268SrStLT5dJImt > qZss9D9rQbSug/WTQAZ5vmY9ODaYbCiZoJ2kThBgI1ENYbm9wNfG/itmH6IBiHjj > 8UZWSYBRKyWTjh7F8EvXUddGOB9U/RV+Sy35IXjIHbGPkGhOedQBKMvZ7WOhqD3U > IFaH8cuCpO7hf+Z9tnDK > =8Bbw > -----END PGP SIGNATURE----- > > -- > 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.
