KillingSpark
A connection should be interruptable while waiting for new messages
This is useful for graceful shutdown of a service. When e.g. SIGTERM is sent to your service just stopping the process is pretty rough. dbus-daemon seems to handle it well enough but it would be nice to actually close the connection properly. For that the reading should be interruptable.
This could be done by using the good ol' reliable self-pipe trick and using select() to wait for data before using a blocking recvmsg. This should also provide a way to send a code so the error handling on the reading call-site knows what's what.
The read loop would look something like this:
loop {
match conn.get_next_message() {
Err(Error::Interrupted(code)) => {/* probably want to return, depending on the user defined code*/}
Err(error) => {/*other error handling*/}
Ok(msg) => {/*message handling*/}
}
}
When creating a conn, a second (cloneable) struct should be generated, that allows to interrupt reads on the conn at any time.
This will contain a Rc<FdWrapper> for the write end of the self-pipe. All it would do is writing the code to the pipe.
FdWrapper will close the contained RawFd on drop.
const INTR_SHUTDOWN: u8 = 0xFF;
conn_interrupter.interrupt_read(INTR_SHUTDOWN).expect("Can't even send interrupts to the conn anymore :((");
Could this instead be implemented by just relying on the behavior of signals? If you're trying to handle a graceful shutdown, and presumably have set a signal handler for SIGTERM or SIGINT; then when receiving a signal, the syscall waiting for a message will be interrupted with EINTR error. This should just be propagated to the caller who can handle it (possibly by gracefully shutting down).
I think this is only true, if the thread that handles the signal is also the one that currently does the read. This is not guaranteed though if you have multiple threads.
Also I think there might be situations where you want to interrupt the reading for other reasons. Maybe you want to restart the connection with a new config or whatever. This is a bit hand-wavy, but if these theoretical issues could be fixed in the same go that would be nice.
Fair enough, I'm sold on this use case.
Hopefully this can be implemented without degrading performance if you use only non-blocking calls in the first place ( I would think you just would skip the select in that case).
I mean it is gonna be a little bit more expensive, but I don't think the syscall-roundtrips make a lot of a difference here. But you are right, if the the call is meant to be non-blocking anyways the select should not be called, so the cost is just an additional branch.