Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explicit initialization/capture of signals #82

Open
vorner opened this issue Jan 3, 2021 · 0 comments
Open

Explicit initialization/capture of signals #82

vorner opened this issue Jan 3, 2021 · 0 comments

Comments

@vorner
Copy link
Owner

vorner commented Jan 3, 2021

As discussed in #78, the current situation in which a library may „steal“ a signal that usually has a default handler can be undesirable. This should be something that is controlled by the application.

The proposed solution is to initialize signals explicitly. The application would call something like init_signal(SIGTERM, SigConfig::default()). That would take over the signal handler, allow libraries to hook into it and say how the library should deal with default handler (emulate it always ‒ see #81, get rid of it, call it if there are no hooks...).

We also need some backwards-compatible way to make the initialization mandatory ‒ registration would error out if that didn't happen.

However, certain libraries already take advantage of this implicit takeover (I've seen multiple async runtimes to do so for SIGCHLD). Possibly the way forward is to allow implicit initialization for signals that have an empty default signal handler (because then the takeover has no effect on the behaviour).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant