Currently cleaning up a task and its continuation is deferred until end of execution. This wastes memory, but is fine for most applications (though I do think there are certain classes of application which do a lot of spawning that will run into issues with the current scheme), and it also blocks the use case I have in mind. Concretely I want to run longer running Shuttle tests in order to set up more elaborate state. I do realize that this is "worse" than making some application specific way to generate state, but I do think adding on-the-fly cleanup together with a way to disable/enable scheduling, such that one can run in "fast mode" (stay on task until blocked / until budget exhausted) to set up state, then run with a scheduler that gets more coverage once state is set up, could be a low effort way to get more confidence in one's application.
It is also nice to not use a bunch of memory we don't need, so if we make this and it works then it should probably be what we always do)
Currently cleaning up a task and its continuation is deferred until end of execution. This wastes memory, but is fine for most applications (though I do think there are certain classes of application which do a lot of spawning that will run into issues with the current scheme), and it also blocks the use case I have in mind. Concretely I want to run longer running Shuttle tests in order to set up more elaborate state. I do realize that this is "worse" than making some application specific way to generate state, but I do think adding on-the-fly cleanup together with a way to disable/enable scheduling, such that one can run in "fast mode" (stay on task until blocked / until budget exhausted) to set up state, then run with a scheduler that gets more coverage once state is set up, could be a low effort way to get more confidence in one's application.
It is also nice to not use a bunch of memory we don't need, so if we make this and it works then it should probably be what we always do)