Provide a convenience API for dispatching blocking work

[aciidgh]

In order to perform blocking work, you current have to either use a DispatchQueue with a promise or setup your own NIOThreadPool. It would be great if NIO can provide a convenience API for scheduling blocking work that returns a future. This could be something like:

extension EventLoop {
    /// Execute the given work on the given queue and notify the future on completion.
    func flatMapBlocking<T>(
        on queue: DispatchQueue,
        work: @escaping () throws -> T
    ) -> EventLoopFuture<T> {
        let promise = self.makePromise(of: T.self)
        queue.async {
            do {
                let result = try work()
                promise.succeed(result)
            } catch {
                promise.fail(error)
            }
        }
        return promise.futureResult
    }
}

[weissi]

Definite yes from me! We should have one for DispatchQueue and one for NIOThreadPool. Implementation looks totally fine to me, thoughts about the name @Lukasa / @glbrntt / @Davidde94 / @tanner0101 ?

[I do like the name exactly as proposed, only thing I'd change is to put a _ in front of work: to make it unnamed :P ]

[Lukasa]

I've written code that's almost exactly like this in a couple of projects, with one exception: I built the function on top of an extension on DispatchQueue. That is, the base functionality is:

extension DispatchQueue {
    func asyncWithFuture<ReturnValue>(
        on loop: EventLoop,
        _ block: () throws -> ReturnValue
    ) -> EventLoopFuture<ReturnValue>
}

Then the composition is very straightforward, and also allows straightforward compositions of the flatMap set that actually pass the result of the future chain:

extension EventLoopFuture {
    func flatMap<NewValue>(
        onto queue: DispatchQueue,
        _ block: (Value) throws -> NewValue
    ) -> EventLoopFuture<NewValue> {
        return self.flatMap { result in
            queue.asyncWithFuture { block(result) }
        }
    }
}

This allows the widest flexibility in composition: if you're Dispatch-first, you have a simple construct like async that gives you a result, whereas if you're NIO-first you have an easy transformation to kick things out to event loops.

Just my 2¢.

[glbrntt]

+1 from me too. I'm okay dropping the Blocking and inferring that from on/onto.

Should we add when{Success,Failure,Complete} variants as well?

[weissi]

I think we should have a word like Blocking or something similar in there. Otherwise it becomes really confusing to the users: You must never block, unless you to a on:/onto: parameter in the flatMap.

[ktoso]

+1 for keeping "blocking" in the name, such things need careful consideration and spelling it out is more important than short method names IMO.

No strong feels about extension being on DispatchQueue or ELF though hm

[weissi]

+1 for keeping "blocking" in the name, such things need careful consideration and spelling it out is more important than short method names IMO.

No strong feels about extension being on DispatchQueue or ELF though hm

I think we should do both tbh. The ELF flatMapBlocking extension is more important for the users but there's no reason we shouldn't also have one on DispatchQueue.

[glbrntt]

I think we should have a word like Blocking or something similar in there. Otherwise it becomes really confusing to the users: You must never block, unless you to a on:/onto: parameter in the flatMap.

True, good point.

[gcjenkinson]

+1 from me too. I'm okay dropping the Blocking and inferring that from on/onto.

Should we add when{Success,Failure,Complete} variants as well?

Just to clarify, the issue here is that you can't invoke a blocking callback from whenSuccess() and so on?

[glbrntt]

+1 from me too. I'm okay dropping the Blocking and inferring that from on/onto.
Should we add when{Success,Failure,Complete} variants as well?

Just to clarify, the issue here is that you can't invoke a blocking callback from whenSuccess() and so on?

Correct, we don't want to do any blocking work on the event loop.