Can signal::unix::Signal::recv ever return None?

[akhilles]

It looks like there's no public API for unregistering a signal stream, so I don't see how recv can ever return None.

[ipetkov]

Today there's no additional way to deregister a signal stream besides dropping it, though it does return Optional to better match and interoperate with other Stream APIs once they stabilize

[akhilles]

Could you clarify how Option<()> return type is better than no return type when working with Stream APIs? Stream<Item = Option<()>> seems as convenient as Stream<Item = ()>.

[Darksonn]

A Stream<Item = ()> corresponds to a poll method that returns Option to indicate the end of the stream.

[akhilles]

signal::unix::Signal::recv isn't a poll method though. It just seems strange to have a function return Option<()> when it can never be None. Are users expected to handle the None case?

[Darksonn]

I agree that it's strange, was just commenting on the Stream<Item = Option<()>> point.

[ipetkov]

Today there is no way to fully deregister signal listeners so practically speaking a None result should never be received (without something going really wrong at runtime). If, in the future, we decide to implement a way to fully deregister signal streams through another mechanism, returning a None value is how we would indicate to the caller that this stream is now defunct.