js promise -> task

[xificurC]

The wiki for task interop uses a dfv with absolve to turn a js promise into a task. Wouldn't

(defn await-promise [p]
  (fn [s f] (.then p s f) #(do)))

do the same with less ceremony?

I'd also add a note that promises futures etc. can't be represented as fully compliant tasks because they can't be canceled nor waited for cancelation to finish.

Would you agree with these 2 changes in the wiki?

[leonoel]

I don't want to encourage this pattern because it's technically a violation of the task protocol, which states that a running task must terminate ASAP on cancellation. All combinators wait for their inputs to terminate before terminating the output, therefore a task ignoring cancellation contaminates the rest of the pipeline. The only situation where it's safe to do so is when the promise is guaranteed to be resolved in reasonable time (e.g because the underlying operation has properly set timeouts). compel has the exact same problem.

I don't mind having a wiki entry about it, but it should be labeled as an expert feature and be very explicit about why it's dangerous, what could go wrong and when it can be used safely.

[xificurC]

I'm not sure I understand, there already is a wiki entry about it, I just found the dfv/absolve code overcomplicated and suggested a simpler solution, which also more clearly shows the violation. Would you agree with the proposed changes or not? I would add more exclamation marks and words like danger here be dragons etc :)

As for interop - you're saying you discourage it and I understand the reasoning. But what is the alternative? Clojure(script) prides itself for its simple host interoperability. I like missionary and would like to interop with existing js code. Is that a bad idea?

[xificurC]

The only cancelation option for promises I found is here https://stackoverflow.com/questions/30233302/promise-is-it-possible-to-force-cancel-a-promise . Not an overall solution unfortunately

[dustingetz]

Have you seen this Peter from the slack channel: https://gist.github.com/dustingetz/d3fb5338b43ef86df5f97387f1d5e249#file-await_promise-clj-L34-L43

[xificurC]

I don't frequent slack, only clojurians zulip. You should join! :) We have a company slack as well and zulip is just so much better structured.

Anyway, thanks for the link! Reading it 3 times makes me understand the chosen implementation a bit more. The naive implementation doesn't ensure that a continuation will be called and can call one even after cancellation. The dfv/absolve combo is pretty complicated to wrap my head around though. So you use a dfv to capture the returned state of the underlying promise, success or failure. Then you wrap it with absolve, which is yet another task. You return the absolve task in the end. So what happens when this task is cancelled?

• absolve propagates the cancellation to its dfv child
• a cancel on a dfv makes its task immediately fail
• absolve can now fail too

So the created tasks from dfv and absolve correctly propagate cancellation, but the underlying promise is none the wiser. What happens if the promise finishes successfully 100ms after the tasks got cancelled? The .then() will still run the success case, right? It would then like to set the dfv, alas that is not possible anymore. The same applies if the promise fails a bit later, the failure case doesn't get to throw because the thunk will never be set in the dfv and will never be called by absolve's task.

I can appreciate the depth of the current implementation now, thank you. It makes the promise behave as good as it can as a task, since there's no good way to kill the process backing the promise. But a cancelled promise-wrapping task will cancel immediately and ignore the underlying promise.

I guess my takeaway is - missionary does the best thing it can when wrapping a promise, therefore where needed it is OK to use it. Where possible we should create our own, better behaved tasks.