Is QueueScheduler still necessary? about reactiveswift

[andersio]

Tried to prototype it and it wasn't quite ideal. The creation and the retrieval of the RAC internal serial queue need extra synchronisation that adds overhead on every scheduling attempt.

[NachoSoto]

Serial execution is importan though. I don't remember the exact context, but RAC 2 had many problems as a consequence of that.

[mdiep]

I think we also need to start limiting changes for ReactiveSwift 1.0.

[andersio]

@NachoSoto It seems RACScheduler had once allowed concurrent execution, but no longer did. That's said we can still accomplish a similar semantic by creating an internal serial queue that targets any arbitrary queue supplied.

[robertjpayne]

EDIT: Ignore me, this is a pretty bad implementation. It's much easier to implement SchedulerProtocol for simple backgrounding via start(on:)

@NachoSoto do you have any more info about why QueueScheduler's need to be serial? I quite frequently have "background" tasks and I just found out that a single QueueScheduler prevents any sort of concurrent execution.

I'm working around this right now by creating a pool of QueueScheduler's and round robin the operators onto them.

It just seems less than ideal…

extension QueueScheduler {
    static var concurrent: QueueScheduler {
        // a single QueueScheduler enforces serial FIFO execution of scheduled blocks. To allow for concurrent execution
        // we instead use a pool of QueueSchedulers and rotate them as they are accessed
        return self.concurrentSchedulers.modify { schedulers in
            let scheduler = schedulers.removeFirst()
            schedulers.append(scheduler)
            return scheduler
        }
    }
    
    private static var concurrentSchedulers = Atomic<[QueueScheduler]>([
        QueueScheduler(qos: .default, name: "concurrent"),
        QueueScheduler(qos: .default, name: "concurrent"),
        QueueScheduler(qos: .default, name: "concurrent"),
        QueueScheduler(qos: .default, name: "concurrent"),
        QueueScheduler(qos: .default, name: "concurrent"),
        QueueScheduler(qos: .default, name: "concurrent"),
        QueueScheduler(qos: .default, name: "concurrent"),
        QueueScheduler(qos: .default, name: "concurrent")
    ])
}

[andersio]

signal.observe(on: ConcurrentScheduler()) would result in a Signal which delivers values in indeterministic order. But it would be an intentional use of concurrent queues, and other than this I was not aware of any context in ReactiveSwift which might oppose such use.