Handle signals with kqueue #112
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We initialized some variables at the top of main(), and some before the first use. Since these variables are used during cleanup it makes sense to initialize all of them at the top. Use one variable per line to make the code easier to read. Signed-off-by: Nir Soffer <[email protected]>
We used sigsetjmp() and siglogjmp() for signal handling, which is very hard to use correctly and too magical. Replace it with the kqueue(), which can notify events on sockets and signals. The get signals with kqueue, we need to block them. This has the nice property that no function in any thread will fail with EINTR when we receive a signal, which simplifies the code. We setup signal handling before we open the pidfile, so receiving a signal after the pidfile was created will always remove the pidfile. Before this change we has a small window when receiving a signal would terminate the process without removing the pidfile. To wait for connection or signal, we wait for kqueue events. If we receiving a signal we break the loop and exit normally, since termination by signal is normal. This can help programs running socket_vment that may be confused by exit code 1. Notes: - Keeping listen_fd in blocking mode to simplify the code. accept() should not block when we receive a EVFILT_READ event. We can change to non-blocking mode later if this assumption is wrong. Signed-off-by: Nir Soffer <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We used sigsetjmp() and siglogjmp() for signal handling, which is very
hard to use correctly and too magical. Replace it with the kqueue(),
which can notify events on sockets and signals.
The get signals with kqueue, we need to block them. This has the nice
property that no function in any thread will fail with EINTR when we
receive a signal, which simplifies the code.
We setup signal handling before we open the pidfile, so receiving a
signal after the pidfile was created will always remove the pidfile.
Before this change we has a small window when receiving a signal would
terminate the process without removing the pidfile.
To wait for connection or signal, we wait for kqueue events. If we
receiving a signal we break the loop and exit normally, since
termination by signal is normal. This can help programs running
socket_vment that may be confused by exit code 1.
Notes:
should not block when we receive a EVFILT_READ event. We can change to
non-blocking mode later if this assumption is wrong.