Design choice question

[davidbrochart]

If I understand correctly, in Effection child tasks cannot outlive their parent but their lifetime doesn't really affect their parent. For instance:

import { run, sleep, spawn } from "@effection/effection";

run(function* op() {
  let task1 = yield* spawn(() => sleep(1000));
  let task2 = yield* spawn(() => sleep(2000));
  // yield* task1;
  // yield* task2;
  console.log('done');
});

Will print done immediatly.
This is different than Trio, where all tasks in a nursery (or task group) must finish before the nursery's context manager exits.
Maybe I am missing something, but otherwise I was wondering about the reasons behind this design choice.

[cowboyd]

in Effection child tasks cannot outlive their parent but their lifetime doesn't really affect their parent.

That is mostly correct, however child tasks do affect the lifetime of their parent insofar as they must exit completely before the parent can exit. The following example derived from yours above will not sleep for a full2000ms, however it will delay 500ms before exiting:

import { run, sleep, spawn } from "@effection/effection";

run(function* op() {
  yield* spawn(function*() {
    try {
      yield* sleep(2000);
    } finally {
      yield* sleep(500);
    }
  });
  console.log('done');
});

It will print "done" immediately, but it cannot exit until the finally block is fully run which includes a 500ms delay.

This is different than Trio, where all tasks in a nursery (or task group) must finish before the nursery's context manager exits.
Maybe I am missing something, but otherwise I was wondering about the reasons behind this design choice.

No, you're not missing anything. In fact, the first version of Effection was loosely based on Trio and it mimicked the same behavior regarding task lifetime. However, we found ourselves still having to spend a lot of thought cycles on explicitly managing children. In our specific case, we were spinning up several operating system processes to act as servers, bundlers, and general workers. When it came time to return from the parent computation (usually because the user hit CTRL-C), we still found ourselves having to do too much management of task cancellation by hand.

It was actually @jnicklas that had the insight that you really only begin a concurrent operation for one of two reasons: Either to produce some persistent side-effect, or else to consume its outcome directly; usually in the form of a value. In the case of the former, there is no need to keep a persistent side effect around once you return from an operation. We found that by definition, there was almost never a time that we wanted to keep things like sub resources and sub processes around, and when there was, it was elegantly handled by spawning in a parent scope that was explicitly passed in. In the cases where a task was spawned concurrently in order to consume a value, the caller would be required to explicitly depend on that value anyway with something like let result = yield* task and so we found that the actual content and scope of an operation very succinctly captured the appropriate lifetime of its concurrent children.

We experimented with appending "a child may not outlive its parent" to the original constraint "a parent is not complete until all its children are complete" and we were very happy with the result: it is very rare that you have to ever do any explicit cancellation or management of resources in Effection. Folks new to Effection are very often surprised by how aggressive it is at tearing down its children at first, but it comes to feel very clean and natural after a very short time. After all, to declare that lifetime is based on nothing more than lexical scope is the essence of structured concurrency, no? Perhaps a more philosophical way to put it is in terms of the proverbial tree in the forest: "If a concurrent operation computes, but there is no one there to listen to its value, does it exist?" our answer is no.

However if you look closely, I do believe that we have preserved, albeit in a slightly modified form, the essential aspect of Trio's guarantee with respect to the lifetimes of its children. As demonstrated in the example above, while Effection will instruct all child tasks to return when a parent task exits, it will still await the outcome of all those returns before it considers itself complete and able to report its result to any callers it might have.

[davidbrochart]

Thanks for the detailed explanation!

The following example derived from yours above will not sleep for a full2000ms, however it will delay 500ms before exiting:

Hmm that's not what I see, it exits immediately on my side.

When it came time to return from the parent computation (usually because the user hit CTRL-C), we still found ourselves having to do too much management of task cancellation by hand.

Well in Trio you would just cancel the task group's cancel scope, right? That would cancel all the child tasks.

[cowboyd]

@davidbrochart When you run the following code:

import { run, sleep, spawn } from "@effection/effection";

run(function* op() {
  yield* spawn(function*() {
    try {
      yield* sleep(2000);
    } finally {
      yield* sleep(500);
      console.log('subtask complete');
    }
  });
  console.log('done');
});

Do you not see "subtask complete" printed to the console? When I run it, I do.

As far as cancellation goes, we just found that certain types of cancellation were always aligned with scope boundaries, and so decided to enforce that as the default. The analogy that we often use is that of releasing the memory allocated to a stack frame when the function call associated with that frame returns. It just happens without you thinking about it, and it's one more piece removed from the cognitive load that you carry.

[davidbrochart]

Do you not see "subtask complete" printed to the console? When I run it, I do.

No I don't, I just see "done" printed immediately. I have deno v2.1.10.

Regarding cancellation, I guess it's really a question of default behavior. When I launch tasks I expect them to run until complete. In Trio there is nothing to do, in Effection I have to yield* all(my_tasks), which adds to cognitive load. But I guess I'm biased because I'm coming from Trio :)

[cowboyd]

No I don't, I just see "done" printed immediately. I have deno v2.1.10.

Hmmm... This seems like a bug, but I'm not able to reproduce it. What version of Effection are you using, and which operating system are you using?

Also, what happens if you use main() instead of run()?

[davidbrochart]

Oh I was on the v4 branch, it works fine on v3. Is this expected?

[cowboyd]

Yes. One difference between v3 and v4 is that in v3, the spawn effect passes control immediately to the child and will run it until it until its first yield point at which time control passes back to the parent. E4 is different in that the parent gets priority and so a spawn effect will immediately pass control back to the parent and the child task will be created and entered when the parent reaches its next yield point.

However, if that yield point never happens and instead the parent exits in the same tick of the event loop that the spawn was requested, the child will never be created at all.

This reasoning behind giving priority to parents is so that they can be more effective at supervision. In other words, if there are two thunks to run in both a parent and a child, and one of them would result in the parent cancelling the child, then we want to run the parent first.

[cowboyd]

Regarding cancellation, I guess it's really a question of default behavior. When I launch tasks I expect them to run until complete. In Trio there is nothing to do, in Effection I have to yield* all(my_tasks), which adds to cognitive load. But I guess I'm biased because I'm coming from Trio :)

I hear you. We just found that there was less cognitive load with the reverse as the default. It might be due to the use-cases we were applying to Effection, but again, we found that if the type of a task was Task<void> and it was being run purely for its persistent side-effects, then the vast majority of the time, we would want to cancel it at the end. To not would be the edge case. However, if the type of the task was Task<T> Where T is some value that needed to be consumed by the operation, then the dependency on task completion to the caller was explicit and the code defined the lifetime of the task without any further intervention.

In other words, the following was very rare

yield* all(my_tasks)

And more often would resemble either:

let my_results = yield* all(my_tasks);

or

return yield* all(my_tasks);

Here is an example from the watch contrib that I've been working on. The watch() itself is a stream of operating system processes that get started in response to file system changes. Here, with each new process, we want to spawn two tasks to pump the stdout and stderr of those processes to the stdout and stderr of the main process. Each turn of the loop stop the previous pumpers and starts a new set. https://github.com/thefrontside/effection-contrib/blob/4a7b62e5bd865b4b9baa5579bb7507a246647560/watch/main.ts#L37-L63 However, because we aren't using these task to compute anything, we don't have to spend any cycles thinking about where to cancel them because they are just side-effects local to the scoped() block.

It is a subtle difference with Trio, but the core invariant of structured concurrency is still present in that any child that has been entered must exit fully before its parent can return. I'm curious what you think of it as you develop more and more in both.

[davidbrochart]

I don't know what to think yet :)
First it's good to acknowledge the differences. Then I'll see when I use Effection if I see myself falling more into its default behavior than Trio's.
Thanks for the help anyway @cowboyd!

[cowboyd]

I think your perspective will be really valuable, and I look forward to hearing about it as it develops. In any event, I feel like we should add this to the FAQ.

Also, If you feel like the explanation is satisfactory, would you mind marking the question as answered? Cheers!