I don't like that suggestion; I'd prefer if coroutines all had `__close` and possibly also `__gc` metamethod that closes them. That way one could just define a coroutine as to-be-closed and things would take care of itself. The `__gc` metamethod would also fix the `coroutine.wrap` problem, but I don't know if it would be a good idea in general, as one might not want to close a coroutine for whatever reason. That being said though, my opinion is that currently `<close>` is completely worthless because it can't be trusted. The whole point seems to be to add a predictable and safe way to make sure something definitely happens, even in case of errors, but that doesn't work because a coroutine can just fall off the counter and cause memory leaks, files that stay open, etc. On 30/07/2020 02:14, Egor Skriptunoff wrote: > Hi! > > 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! > > If a coroutine is created with coroutine.create, > we need to not forget to invoke coroutine.close somewhere before the > program exits. > And if a coroutine is created with coroutine.wrap, > we don't even have the ability to invoke coroutine.close! > As a result, we have to duplicate all __close functionality in finalizers. > Why such inconvenience? > > 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. > This way we could forget about __gc and work only with __close. >
Attachment:
signature.asc
Description: OpenPGP digital signature