Conditions: document that conditions can only be handled in the same task

[catamorphism]

If task A spawns task B, and B has an unhandled condition, that manifests as task B failing -- any handlers in A won't get invoked. This was pretty sensible once I thought about it, but it surprised me at first. I think the conditions tutorial should mention it.

[catamorphism]

I'm wondering if this is a good thing, actually. Suppose I want to spawn a task, and execute some code that might raise condition A, B or C. Whereas in the single-threaded case, I would be able to do:

A.trap(a_handler, B.trap(b_handler, C.trap(do_work())))

and know that my handlers would trap all the conditions, if do_work spawns tasks internally, and if the work done inside the tasks would raise conditions, then the handlers don't suffice and rather, inside do_work, I have to repeatedly check for task failure, decide whether the task failure was because of a condition, and then re-raise a condition of necessary. It seems kind of like an abstraction violation that I have to know whether or not do_work spawns any tasks to know, in the above code, whether I could possibly get an uncaught A, B or C condition.

Maybe I'm just trying to use conditions for something they shouldn't be used for, though.

[nikomatsakis]

This is an interesting point. I do think that this is how conditions
should work, but it's an unfortunate interaction. I feel like there
is potentially a need for three kinds of parallel "processes":

• Tasks as we know them today. Memory independent actors that run
  asynchronously from one another.
• "Synchronous" tasks for containing failure. Memory independent but
  their lifetimes are linked to the parent. In other words, you don't
  just spawn them and let them run, but rather spawn them and they
  are implicitly joined.
• Parallel jobs. These may share memory and are intended to divide
  up parallel work, like processing every element of an array in
  parallel. Because the memory spaces are linked, failure in a job
  propagates to its parent.

Conditions in the parent would be in scope for the latter two, but
not the first one.

[basic-calculus]

This sort of relates to how RWArc variables can be poisoned by write actions failing, or how Java's FutureTasks can be poisoned. Maybe if there was some-way to register the condition before failure, and then reinvoke the task if appropriate? So far, I'm thinking of something along the lines of future.recv(|c| c.reinvoke(0)) // Provide a default value of 0 in case we have an exceptional condition. This exact interface is problematic though because than tasks could be left as garbage waiting to know if they should fail, or not.

[owaspjocur]

@catamorphism This fix is actually updating the conditions tutorial? or after reading the reactions, there are some issues regarding how conditions and tasks interact. Let me know in which direction this issue is going

[pnkfelix]

part of #11755

[pongad]

Delete issue because conditions are removed?

[alexcrichton]

Indeed, thanks @pongad!