SIGHUP channel should be buffered

[marco-m]

ciao Filippo,

according to the signals.Notify documentation, the channel should be buffered:

Package signal will not block sending to c: the caller must ensure that c has sufficient
buffer space to keep up with the expected signal rate. For a channel used for notification
of just one signal value, a buffer of size 1 is sufficient.

I have to admit that I have always been partially confused by this requirement and by the various discussions that pop up from googling the subject.

Maybe in this particular case there is no practical difference but I noticed it:

yubikey-agent/main.go

Line 42 in 0096c09

c := make(chan os.Signal)

[awnumar]

I have to admit that I have always been partially confused by this requirement and by the various discussions that pop up from googling the subject.

I assume it's because an unbuffered channel would block the sender and you don't want the runtime to block.

[FiloSottile]

The runtime will drop the signal on the floor if the channel is not ready, that's why the docs recommend a buffered channel. In this case the channel won't be ready if (1) the loop hasn't started yet or (2) a Close is already in progress.

(2) is arguably good, we don't want to drop the connection twice in that case. I thought (1) was fine too, but then I realized there is no guarantee of when the goroutine will start, so technically this is not airtight. On the other hand, if the goroutine never starts, the point is moot because the signals will not get processed. The buffer only helps with a signal that arrives before the loop starts, which in practice should be a narrow window.

On balance, I think it's fine to use the unbuffered channel.

[FiloSottile]

(But thank you for looking at the code and reporting this! Glad to know there are eyes on it!)