yield from __close

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

yield from __close

John Belmonte
Being able to block at scope exit (in Lua, from a "__close" metamethod hand control back to the coroutine scheduler via "yield") is fundamental to implementing structured concurrency.

Would there be any way to lift this restriction from the to-be-closed implementation?

  coro = coroutine.create(function()
    local foo <close> = setmetatable({}, {
      __close = function(a) coroutine.yield('bar') end
    })
  end)
  assert(coroutine.resume(coro))

  --> "attempt to yield across a C-call boundary"

Reply | Threaded
Open this post in threaded view
|

Re: yield from __close

Roberto Ierusalimschy
> Being able to block at scope exit (in Lua, from a "__close" metamethod hand
> control back to the coroutine scheduler via "yield") is fundamental to
> implementing structured concurrency.
>
> Would there be any way to lift this restriction from the to-be-closed
> implementation?

I don't see any conceptual problem, but I don't have a clear idea of how
hard it would be to implement it.

It seems that we could add a bit in callstatus that we are running a
"__close" metamethod and then allow yields. In case of yield, after
finishing the function, 'unroll' have to check that bit and, if true,
continue the interrupted work (remove the upvalue from the list and
run the other pending closes).

All very slippery code :-)

-- Roberto
Reply | Threaded
Open this post in threaded view
|

Re: yield from __close

John Belmonte
I think it would be worth it.  It enables, for example, anything that can be done today using Python's async context managers (including structured concurrency).

I have the start of a structured concurrency implementation prototyped in about 200 lines of Lua.  Fairly exciting, and I was looking forward to posting some articles as things progressed-- but the yield issue is a show stopper.


On Sat, Oct 3, 2020 at 1:40 AM Roberto Ierusalimschy <[hidden email]> wrote:
> Being able to block at scope exit (in Lua, from a "__close" metamethod hand
> control back to the coroutine scheduler via "yield") is fundamental to
> implementing structured concurrency.
>
> Would there be any way to lift this restriction from the to-be-closed
> implementation?

I don't see any conceptual problem, but I don't have a clear idea of how
hard it would be to implement it.

It seems that we could add a bit in callstatus that we are running a
"__close" metamethod and then allow yields. In case of yield, after
finishing the function, 'unroll' have to check that bit and, if true,
continue the interrupted work (remove the upvalue from the list and
run the other pending closes).

All very slippery code :-)

-- Roberto
Reply | Threaded
Open this post in threaded view
|

Re: yield from __close

Matthew Wild
On Wed, 7 Oct 2020 at 13:15, John Belmonte <[hidden email]> wrote:
>
> I think it would be worth it.  It enables, for example, anything that can be done today using Python's async context managers (including structured concurrency).
>
> I have the start of a structured concurrency implementation prototyped in about 200 lines of Lua.  Fairly exciting, and I was looking forward to posting some articles as things progressed-- but the yield issue is a show stopper.

Have to agree that this is an important feature, I hadn't got as far
as implementing it but I was not aware of this limitation.

Regards,
Matthew