Coroutine __close metamethod proposal

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Coroutine __close metamethod proposal

Sergey Zakharchenko
Hello list,

Does it make sense to give coroutines a metatable that would have
__close call coroutine.kill ? I think this can likely be done using
the debug library, but it seems to be natural behaviour to use as
default...

Best regards,

--
DoubleF

Reply | Threaded
Open this post in threaded view
|

Re: Coroutine __close metamethod proposal

Philipp Janda
Am 31.05.19 um 13:05 schröbte Sergey Zakharchenko:
> Hello list,

Hi!

>
> Does it make sense to give coroutines a metatable that would have
> __close call coroutine.kill ? I think this can likely be done using
> the debug library, but it seems to be natural behaviour to use as
> default...

And maybe functions should have a default toclose behavior as well.
Anyway, we probably want the `local <const> function f() ... end` syntax
sugar even if functions don't get a default toclose behavior.

>
> Best regards,
>

Philipp



Reply | Threaded
Open this post in threaded view
|

Re: Coroutine __close metamethod proposal

Andrew Gierth
>>>>> "Philipp" == Philipp Janda <[hidden email]> writes:

 Philipp> And maybe functions should have a default toclose behavior as
 Philipp> well.

The ability to use a function as a toclose value previously existed, but
was removed - I guess (from the timing) as a result of a discussion I
had on the list about how a restricted environment needs control over
what happens in error handling.

As it stands, if an environment doesn't expose setmetatable() to the lua
code, then it can ensure that the lua code can't get control over error
handling other than with pcall, which the environment can intercept.

--
Andrew.

Reply | Threaded
Open this post in threaded view
|

Re: Coroutine __close metamethod proposal

Roberto Ierusalimschy
>  Philipp> And maybe functions should have a default toclose behavior as
>  Philipp> well.
>
> The ability to use a function as a toclose value previously existed, but
> was removed - I guess (from the timing) as a result of a discussion I
> had on the list about how a restricted environment needs control over
> what happens in error handling.
>
> As it stands, if an environment doesn't expose setmetatable() to the lua
> code, then it can ensure that the lua code can't get control over error
> handling other than with pcall, which the environment can intercept.

Right. And there is one more reason:

    * Functions interact badly with coroutines. If a coroutine yields
    and is never resumed again, its to-be-closed functions will never
    run. To-be-closed objects, on the other hand, will still be closed,
    provided they have appropriate finalizers.
   
-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Coroutine __close metamethod proposal

Andrew Gierth
>>>>> "Roberto" == Roberto Ierusalimschy <[hidden email]> writes:

 >> The ability to use a function as a toclose value previously existed,
 >> but was removed - I guess (from the timing) as a result of a
 >> discussion I had on the list about how a restricted environment
 >> needs control over what happens in error handling.
 >>
 >> As it stands, if an environment doesn't expose setmetatable() to the
 >> lua code, then it can ensure that the lua code can't get control
 >> over error handling other than with pcall, which the environment can
 >> intercept.

 Roberto> Right. And there is one more reason:

 Roberto> * Functions interact badly with coroutines. If a coroutine
 Roberto> yields and is never resumed again, its to-be-closed functions
 Roberto> will never run. To-be-closed objects, on the other hand, will
 Roberto> still be closed, provided they have appropriate finalizers.
   
Incidentally, in my case, hiding setmetatable() from the application
would be highly undesirable, so I'm looking into whether it's possible
to prevent the code from creating a __close method by wrapping
setmetatable() and rawset().

--
Andrew.