libuv handles keep foreign look alive

[saghul]

Hey there!

Here is a "fun" problem I ran into when integrating lws into my small JS runtime (it's currently used for HTTP/WS clients and servers).

I'm using libuv as my platform layer, so there is already a loop going on, thus, I'm using lws with a foreign event loop: https://github.com/saghul/txiki.js/blob/b88afe7bbd0c2a5d695c217f114d06195a77c9c1/src/lws-utils.c#L202

I also enabled async DNS because I don't want DNS to block the JS event loop.

lws seems to create a number of internal uv handles (poll handles, the pipe for wakeup, etc).

The problem arises when some of those handles keep the libuv event loop alive, since that affects my runtime, as uv_run won't exit because of those handles.

In order to get going I'm currently patching lws to not ref any uv handles: https://github.com/saghul/txiki.js/blob/master/patches/lws.patch

This is not ideal, so my plan was to bring it up here once I had things working. That time is now! :-)

My thinking here is that when lws is used directly there is no change necessary. When used with a foreign event loop, consumers may want the handles to be unref'd in order to keep a tighter control over loop exit conditions. I wonder if some kind of flag during context creation would be acceptable?

There is an interesting situation, however: when async DNS is used, one would want DNS to take place, so I do want those handles to be ref'd. Since I couldn't tell the difference (I'm not very experienced with the internals) I went the easy route and unref'd everything, then relied on an async handle I created to decide when to keep the loop alive.

Is this something that has come up? I'm willing to provide a patch once we agree on the path forward :-)

Another option I thought of, but I'm not sure it's currently possible is to write my own event loop integration plugin. If it was possible to do that externally (ie, not require it be baked into lws) that would also work. Thoughts?

Thanks for lws! ❤️

[lws-team]

I'm not sure we're 100% aligned with what we're talking about, but I still have the scars from man-months implementing libuv support "cleanly", so I feel I have some kind of perspective and we can iteratively figure out what's missing.

It's best to use a foreign loop... the idea for that is lws should be able to come on the preexisting loop, do its jobs and then leave it completely cleanly, with the foreign loop still standing and anything that was natively created against it outside lws, untouched.

The problem with wrapping the libuv stuff "as a convenience" with the lws lifecycle is every other loop has the close as single event. Only libuv has a multi-part close where there's no guarantee that finalizing the close is going to happen synchronously. So lws feels that destroying the context should be a synchronous event, but libuv has made it something that happens itself on the event loop. So it's better to roll with that and take on the event loop lifecycle yourself outside of lws.

When you say "lws seems to create a number of internal uv handles (poll handles, the pipe for wakeup, etc)." since libuv controls the wait, if you build with libuv support, any fds that lws wants to wait on, must have a footprint in libuv. For fds that are in a vhost context, lws cleans them up nicely by doing a mass close on them, and refcounting them until there are none left open in the vhost, when it can finalize the vhost close, and when all the vhosts down, the context close.

For other fds like the wait-cancelling pipe, they're done via the lib/plat stuff, they should also be closed by that when the context goes down.

[saghul]

Thanks for replying! I think I forgot something important here 😅 Destroying lws is ok, because I do run the loop after to make sure there was time for all callbacks to run.

The problem is that uv_run(loop, UV_RUN_DEFAULT) won't return if there are active ref'd handles that lws still keeps, and in a nutshell, that's how the txiki.js event loop exits today. So any pipe or timer handle prevents my main loop from exiting.

Yes it will once I destroy lws, but the point is detecting "there is nothing else to do" becomes hard because from my app's prespective lws seems to still have things to do.

Does that help understand the use case?

PS: I've coincidentally been a libuv maintainer for may years now. FWIW, the reason for uv_close being async is that some resources cannot be destroyes synchronously.

[lws-team]

from my app's prespective lws seems to still have things to do.

Why does your app feel that this is the case? It should know that it destroyed the lws context?

the reason for uv_close being async is that some resources cannot be destroyes synchronously.

This doesn't make me any the wiser... in the underlying C apis, things can be closed synchronously, indeed every other event library that I know of does do it synchronously.

[saghul]

Why does your app feel that this is the case? It should know that it destroyed the lws context?

I'm only destroying the context after uv_run returns, which is when the JS event loop is done. I then call uv_run again, after destroying lws, to give the close callbacks a chancem, with UV_RUN_NOWAIT this time.

Are you saying that creating and destroying the context would be the way to go here? Sounds a bit too involved.

This doesn't make me any the wiser... in the underlying C apis, things can be closed synchronously, indeed every other event library that I know of does do it synchronously.

Not in Windows with IOCP.