Re: To-be-closed variables and coroutines

[DarkWiiPlayer <darkwiiplayer@...>]

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