The issue is waiting for threads at runtime, at fixed boundary points, not statically determining if they halt or not.

The halting problem is irrelevant to this discussion.

Well.. whatever. You can provably determine whatever irrelevant point you want I guess.

If a naively spawned task or routine can be artificially restricted at a boundary point, that's enough for me.

You could without question implement this by binding child tasks to the threadlocal context on spawn and wait all on a dispose block in c#; certainly if you explicitly went out of your way to swap to a different sync context it would break but so what?

You can always unsafe your way into a hole in any language.

>If a naively spawned task or routine can be artificially restricted at a boundary point, that's enough for me.

Ok, and you have three options to do this:

1. Block 2. Opt into some system that allows you to defer blocking until later 3. Know when the callback will finish

1 isn't async, 2 is an opt in system, and 3 has a prerequisite of the halting problem.

That's it. You can restrict yourself to not using primitives like `Thread`, and instead only use futures or async/await style things, and that's a valid solution. Hell, your language could not expose a Thread primitive at all. But its solution #2. You cannot just take a look at arbitrary code and pick a point or points where thread execution is restrained.

If you can, it's because the language you're using prevents you from doing certain things. (for example, opting in to "all threads must be promises, and all promises must be awaited)