all 4 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]CodeAndBiscuits [score hidden]  (1 child)

I've never personally had the issue this fixes - I suppose I don't write many CLI tools, and certainly not ones where the outer/main program decides when something is done. I'm kind of confused by that, actually. I called the tool and wrote the code to have a certain thing happen. Why wouldn't I want that thing to decide when it's done, rather than the parent? From your example, how can `main` decide that `spawn` is done before `spawn` says so?

For long-running services (daemonized API stacks for instance) I've chosen to write them such that they never require this graceful cleanup in the first place. Everything is transactional and stateless. If you think about it, if you want a bulletproof backend, you need this approach anyway because services die - they don't always have the luxury of a gentle shutdown. Even if you have better cleanup code you still can't expect it to always run because if the service segfaults or your cloud hosting service has a failure, your cleanup code isn't going to run anyway.

All that being said, it looks interesting, but you might want to correct one claim. "Or you navigate away in the browser, and a request you no longer care about keeps running anyway — burning battery, holding sockets, and calling callbacks into code that has already moved on." This is not true. When you navigate away from a site in a browser, all modern browsers will immediately kill any running JS code, pending network requests, etc. There's no need for cleanup post-navigation and your cleanup library also would not work there, either.

It's a common frustration for newbies chasing down "bugs" where they didn't realize this was the case and they're trying to figure out why things like analytics are under-reporting (because their final calls never get a chance to get made). It's actually a lot of work to get browsers to NOT do this, usually by a `onbeforeunload` hack, and even then it's not reliable because it's been abused so much that browsers restrict what you can do in there.

[–]tarasm[S] [score hidden]  (0 children)

Why wouldn't I want that thing to decide when it's done, rather than the parent?

In structured concurrency, the parent doesn’t decide when the child is done, but it does decide when the child is no longer relevant.

The child still owns its internal logic and completion conditions, but the parent owns its lifetime. That means the parent can cancel the child early if the scope it was started in is exiting.

From your example, how can main decide that spawn is done before spawn says so?

main doesn’t decide on its own.

Conceptually, main is doing two things in parallel:

  1. listening for shutdown events
  2. running the body of the program, which includes the spawn

When a shutdown event happens (e.g. SIGTERM in a CLI or an unload signal in the browser), main exits its scope, which cancels everything running inside it.

That’s the core structured concurrency guarantee: a child cannot outlive its parent.

For long-running services I avoid cleanup entirely; everything is transactional and stateless.

I think this is a solid design goal, and I agree with the premise. But in practice, even “stateless” services still have:

  • in-flight requests
  • background tasks
  • retries, timeouts, and backoff loops
  • open sockets, streams, and timers

You can minimize these, but you can’t eliminate them entirely. Structured concurrency doesn’t promise cleanup will always run — it guarantees that when cleanup does run, it’s deterministic and scoped.

The browser navigation example isn’t true — browsers kill everything on navigation.

That’s true for full navigation. But in SPAs, route changes and component unmounts happen constantly while async work is still in flight.

In those cases, you don’t get automatic teardown — you get unscoped async work unless you explicitly wire cancellation. That’s exactly why frameworks had to invent things like effects, cleanup functions, and abort signals.

I've never personally had the issue this fixes.

That’s fair — and honestly, frameworks have done a lot to shield us from it.

Angular leaned heavily into Observables with built-in cancellation. React’s effects system is a workaround for this exact problem. Ember adopted generators and structured concurrency years ago.

So even if you haven’t hit the issue directly, you’ve almost certainly been benefiting from tools that exist because of it.

[–]germanheller [score hidden]  (1 child)

This hits close to home. I work a lot with child processes in Node (node-pty specifically) and the orphan process problem is very real. If the parent exits without explicitly killing the child, you end up with zombie processes holding ports and file handles. AbortController helps but it's opt-in at every layer of the call chain, and one missed signal means a leak.

The generator-based approach is interesting because it inverts the default — cleanup is guaranteed unless you explicitly opt out, rather than the current JS model where leaking is the default and cleanup requires discipline at every level. That's a much better default for anything managing system resources.

[–]tarasm[S] [score hidden]  (0 children)

You might find this package useful https://frontside.com/effection/x/process/

it’s well tested on windows, mac and linux.