The reason and use cases behind special treatment for .interrupted event.

[reactivecocoa]

The reason and use cases behind special treatment for .interrupted event.

[mdiep]

I don't fully understand this part of the code yet, but .interrupted can propagate up the signal chain when something is disposed or interrupted.

[andersio]

A started SignalProducer is allowed to be interrupted in the observer it is started with. Since we serialise events using sendLock, such use would deadlock unless it is treated specially (and it is).

[kAzec]

Oh, thanks, now I see.

[andersio]

A code snippet to illustrate this if you are interested.

let (signal, observer) = Signal<Int, NoError>.pipe()
var disposable: Disposable?

disposable = SignalProducer<Int, NoError>(signal: signal)
    .startWithValues { _ in
        print(disposable)
        disposable?.dispose()
    }

observer.send(value: 1)

The value event is pushed to the produced signal, causing a disposal of the producer. Since by default everything is synchronous, if we do not treat interrupt specially, we would stuck at attempting to lock sendLock again within the critical section of sendLock (the value event).

[kAzec]

Understood. And also under the following condition which may be more common:

signalProducer
    .startWithSignal { signal, interrupter in
        signal.observe { event in
            // ...
            interrupter.dispose()
        }
    }