handling properly SIGTERM etc....

[bstarynk]

The file examples/hello/hello.c has a wrong SIGTERM handler which is not async-signal-safe (because onion_listen_stop is not async-signal-safe since it calls indirectly non-async-signal-safe functions). See signal(7) and signal-safety(7) for more.

I believe that if libonion has some async-signal-safe functions (and it probably don't) they should be properly documented as such. Remember that async-signal-safe functions are forbidden to use <stdio.h> or malloc or free (even indirectly) .... But most system calls (such as read, write, poll) are async-signal-safe.

Perhaps libonion should at least document how to handle SIGTERM properly. That could be as simple as saying that some extra thread should handle it. As an example of nice documentation related to that, see (for the Qt toolkit) the Calling Qt Functions From Unix Signal Handlers.

It would be however better if Onion would have some support for SIGTERM. One could imagine to add some onion_add_sigterm_handler routine. That would work like for Qt: make some pipe(7) to self, then install some internal SIGTERM handler which just write(2)-s to that pipe (remember that write is async-signal-safe!), and organize the Onion polling loop to handle the read end of that pipe (and do the actual SIGTERM processing from the polling loop, so the handler passed to onion_add_sigterm_handler could call most onion functions, notably all the non-async-signal-safe ones, such as onion_listen_stop).

Actually, I would prefer to be able to terminate properly my Onion application (if you are curious, it is bismon...) in two ways and I am coding Onion related stuff right now (in end of june and july 2018). I would like to terminate my Onion application with both SIGTERM and SIGQUIT. Since SIGTERM would save the internal state of bismon, but SIGQUIT won't save it.

I am not able to design such an onion_add_sigterm_handler routine alone without guidance, because I don't understand well enough the Onion event loop and polling machinery (which is not enough documented).

BTW, it is probably impossible (or quite difficult) to design a SIGTERM mechanism which works with several onion objects. I'm believing that libonion is basically expecting each application to have only one onion object (given by onion_new). That could also be documented. If there is a practical possibility to have several onion-s in an application (I would guess that no), it should be explained (perhaps with some example).

See also this message on onion list.

[bstarynk]

There might be some issue with current SIGTERM handling in Onion. See the following message.