Don’t attempt to remove elements of empty queues.

[robrix]

Fixes a crasher.

[jspahrsummers]

This seems like a good idea no matter what, but I'm struggling to understand the chain of events that could lead us here.

It seems like we only try to dequeue a signal producer if one has just completed or interrupted, so shouldn't there be a one-to-one correspondence there? 😕

[robrix]

Yeah, it’s unclear how this is happening—perhaps threading hijinks in my exploration of the deadlocks?

I was misinterpreting this use of the method as intending it to be empty sometimes, rather than intending it to be emptied by the call—mea culpa.

[ikesyo]

From what I experienced, the following code prevents the crash (but I didn't understand why):

    func startNextSignalProducer(signalProducer: SignalProducer<T, E>) {
        signalProducer.startWithSignal { signal, disposable in
            self.disposable.addDisposable(disposable)

            let d = signal.observe(Signal.Observer { event in
                switch event {
                case .Completed, .Interrupted:
                    if let nextSignalProducer = self.dequeueSignalProducer() {
                        self.startNextSignalProducer(nextSignalProducer)
                    }

                default:
                    self.observer.put(event)
                }
            })
            self.disposable.addDisposable(d)
        }
    }

[jspahrsummers]

Well, this certainly can't hurt, so I'll merge it.

[jspahrsummers]

I just saw a bad access on this line (post-PR). Not sure how that's possible. 😕

[robrix]

I think that means either concurrency bug or Swift bug.

[jspahrsummers]

why not both???

[NachoSoto]

He said or not xor 😃

[robrix]

With Swift, both is practically guaranteed.