To-be-closed variables were introduced as a more strict (and preferred) mechanism than GC finalizers.
But in suspended and normal coroutines the __close metamethods does not run on program exit!
...
To-be-closed variables should be reliable and self-sufficient.
The suggestion:
When VM is closing, coroutine.close() should be automatically invoked for every non-dead coroutine in the VM.
The use case you have in mind may be relatively simple, like freeing some OS resource. But in the general, tasks of a concurrent program may want to do the following at shutdown:
- asynchronous operations under the cooperative scheduler (IO, networking, etc.)
- operations that depend on other tasks in the application
I haven't tried to implement such a system in Lua, but do have experience with Python Trio, which is one of frameworks at the forefront of structured concurrency.
Essentially, #1 is going to require cooperation from the task/coroutine scheduler. It needs to intercept SIGINT / SIGTERM / keyboard interrupt and propagate a cancel signal to all the active tasks, giving their finalizers a chance to run. In Trio, by default any attempt to block from a task in a cancelled state will raise an exception (which in turn propagates to child and parent tasks). However, it also has a "shield" feature (usually employed with a timeout), where finalizers can opt in to blocking from a task that is pending cancellation.
Item #2 builds on #1 and is harder to manage. For example, we have a companion robot-- when the top-level control process receives a SIGTERM, that process is still able to shut down the servos and close the eyelids (requiring networking, animation, and other services provided by other tasks).
The general area is referred to as graceful shutdown-- still a hot topic in the structured concurrency forums.
For Lua, I'm expecting that the to-be-closed variables and coroutine API are sufficient to build upon.
Regards,
--John
