On Wed, Feb 21, 2018 at 8:05 PM, Ben Noordhuis <[email protected]> wrote: > On Wed, Feb 21, 2018 at 8:51 PM, Gábor Csárdi <[email protected]> wrote: >> Dear all, >> >> I am trying to wrap libuv as an extension package for an environment. It >> seems mostly straightforward, and I'll just run a libuv event loop in >> another thread, they can communicate via pipes. >> >> However, there is a potential issue with signals. The host environment >> handles some signals, and AFAICT libuv does use a couple of signals for its >> own purposes. E.g. they can both start child processes, and they set a >> signal handler for SIGCHLD. Actually, AFAIR libuv sets up some signal >> handlers already when an event loop is created. >> >> I realize that this is not a very specific question, but how much does libuv >> rely on the signals? E.g. if some signals are not delivered (e.g. a child >> process exits, and libuv does not get SIGCHLD), can I expect some reasonable >> behavior, or is that undefined behavior? >> >> Is there a libuv policy for signal handling? I.e. which signals are safe to >> handle by the user or host environment? >> >> Any help or pointers are greatly appreciated, thanks, >> Gabor > > Libuv needs to own the SIGCHLD signal handler if you want to use > uv_spawn(), otherwise you're free to do as you please. If libuv > doesn't receive the signal, that's effectively UB: things will break > in unpredictable ways.
Thanks, this is really helpful! I get live without uv_spawn, since I can already spawn from the host environment, and I can probably this add these handles to the libuv event loop, if I need them there. So that should be fine then. Not ideal, but manageable. > If that's problematic for you, can you open an issue? Perhaps we can > work out something that lets signal handlers chain or lets your signal > handler push events to libuv. Unfortunately chaining signal handlers needs cooperation from all parties, and I don't have access to the core of the host environment (can only write dlopen()-d modules to it). So this will not work in my case, because the core of the host just overwrites the libuv signal handlers. > A different but somewhat related issue is that the host application > should usually block, handle or ignore SIGPIPE. Libuv will run > correctly if you don't but because SIGPIPE normally terminates the > process, and because most socket operations can generate SIGPIPE > signals, the net effect is usually a program that ends prematurely. Yes, the host handles SIGPIPE already, so this should be fine. It also handles SIGSEGV, SIGILL, SIGBUS, SIGINT, SIGUSR1, SIGUSR2, I guess libuv would not touch these. Thanks much, this is looking great then! Gabor [...] -- 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 https://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
