-
-
Notifications
You must be signed in to change notification settings - Fork 50
Is Future.map(on: worker)
intentionally synchronous?
#167
Comments
PS: I'm happy to put up a PR to execute the promise on the event loop, but I wasn't sure what the intended behavior here was, hence this discussion issue first. If there's a better venue for this question, I am happy to redirect! |
Normally the block inside `map` only gets executed once the previous future is fulfilled, so in that case the block will be run on the event loop anyway, I guess? (Not sure hat happens if the previous future has already been fulfilled at the time when `map` is called, though. Also, I might be misunderstanding something.)
… On 31. Jul 2018, at 15:28, Brian Hatfield ***@***.***> wrote:
PS: I'm happy to put up a PR to execute the promise on the event loop, but I wasn't sure what the intended behavior here was, hence this discussion issue first. If there's a better venue for this question, I am happy to redirect!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
@MrMage There's no previous Future here, the static The question is valid. The only difference between the NIO and the Async functions is which thread the synchronous function is executed on: as noted, Async's |
@MrMage: @vzsg has understood it right - I am asking about the static It's of course possible to use Promises directly to create new futures, but I found the static As mentioned - if it's an oversight, the PR here is very straightforward, should be backwards-compatible, and I am happy to make it. |
Sorry for jumping in, I should have looked at the code 😅 Didn't mean to detract, just wanted to be helpful :-) |
@bmhatfield That said I don't think there would be a huge detriment to putting these calls onto the event loop. The only thing I would say is that we should only call |
When working with Vapor, I recently was surprised to learn that
Future.map
was a synchronous method that returns a future. I had been under the mistaken impression that it executed the closure on the event loop.Compare: https://github.com/vapor/core/blob/master/Sources/Async/Future%2BGlobal.swift#L11-L21
with
.submit
: https://github.com/apple/swift-nio/blob/ae13d135f79e7b60281f9bf4c1cf1b3341a7339f/Sources/NIO/EventLoop.swift#L268-L280Just checking that this wasn't an oversight, because the two methods appear to be very close in implementation.
The text was updated successfully, but these errors were encountered: