-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey Trevor,
On 04/11/2014 02:42 AM, Trevor Norris wrote: > I'd like to have a discussion on the possibility/difficulty on > making libuv thread safe, what are the trade offs in terms of > performance, etc. > > I'm finding myself in a position where needing to sink with the > main thread in order to init stuff like timers is very costly. As > far as I can see from the *nix side the main issue is because of > the way handles are placed in the queue. Though I'm not familiar > with how it is handled on the win side. > Can you elaborate on what you are trying to achieve? What platforms do you need to support? One possibility would be to use a model similar to test-embed.c: have the uv loop stopped, create handles from your main thread, block for i/o on an auxiliary thread (uv_backend_fd + uv_backend_timeout), signal the main thread, and there uv_run with UV_RUN_NOWAIT, so that all callbacks are fired. There might be other ways to tackle your problem, but without any more details this is the first thing that came to mind. The reason why I say this is because I'm -1 on thread-safety for libuv. I wasn't around back then, but assuming libuv followed some of the design principles of libev, the idea is to not be thread safe but be thread "friendly" in a way. That is, by not having global state and providing some sort of context that can be mapped to a thread. In this case, that context is the loop. > I'm willing to give it a go, but would like feedback before > attempting such an endeavor. > This would be a huge task. It may even result in a change in libuv's design (hard to tell, but still). FWIW, here is a rough example on what would be needed to make timers thread safe (at a back-of-a-napkin design level): - - we'd need to have a per-loop lock, that would be recursive, because all functions need to be protected by it, also during callback execution - - uv_timer_init adds the handle to the loop's handle queue, so it needs to hold the lock - - uv_timer_start initializes some fields in the timer structure + adds the timer to the active queue + adds the timer to the timer heap, so it needs to hold the lock - - uv_run iterates over the timer heap to find expired timers and fire callbacks + takes the smallest active timer to use it as timeout for polling (other things are also considered, this is a simplified version), so it needs locking This is just timers. So IMHO the added complexity plus the potential performance impact due to the locking (even if they are essentially free if not contended, uv_run needs to be locked-unlocked, and is the main loop) would not give you an advantage. Those are my 2 cents. If you provide more details on what you are tying to do I might be able to help with a more detailed approach. Cheers, - -- Saúl Ibarra Corretgé bettercallsaghul.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJTSPFeAAoJEEEOVVOum8BZO64P/j2cMZ3+lXTwIIs0PlYFS42V G9ACPMQZwTZzxNpYFbF/psHPrfJdzlXou7kiLKgAY44V7H4u1nkrwXP2q4MXwo/s Jd8eOALgBgWfrXIH7Wzp/9KUJSBafNdYGY/5AgaHq9hv9qDtNhdsxAmotS/2jw7s ObKs9LGWaihab+E4EEdyDuFJp5upT6S8bEV0HQVGjMplVonCbA/vViqP5up7+yKx DSEb/tNlxjAOOBynBNjKYCOFpk0Nk+MhTFUIOxeNQJ7NFbFmzhXLpPBHDVSj7FC4 uOGfo1sAzLiaZNJT5T4rInHSSPD8udbtOsxJrGhb5VMIaqcOgDULqXnbBgZFGBrE hqp36HS9+a377cQksKD8VFk8TZyRJ8G+YduJTInUwTOERVdFFHbQ2aMDShqG+hhs MS2QR1A4rK4lJEQ4pZOJmfsQgBOIoz7yD6DQuoDI94vU204HQlieFKdels80rk6l ZQgZB5PVxqXGRUULm5RSwEcpvmhAH+rZ0+4NcYic8k2N2c8Sc+iTaBmU1SBcRXj2 //iJQgsBLCWZMWI8rDs9kX4M7f4s7xr+i2QhfugMw6kkcCrA3GOIGTEwq9p/H+CG z0xHiZti74SHWW696n9zYsvK1XkLC22QBIGD+wIwb4m5iV8aofRUAXFfr+sVsW/u cpIZItx0we/gFlaILfbW =ig4e -----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.
