(not) handling new programming idioms with grace

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

(not) handling new programming idioms with grace

John Belmonte
It's been about 10 years since my post "state of the Lua nation on resource cleanup" [1].  The only relevant thing that's happened in this area since then was Lua getting pcall + coroutine love in 5.2.

My position on Lua's need for some type of scope exit hook is only stronger these days.  It's not just about resource cleanup.  For example, there are some very interesting concurrency and cancellation control structures being developed as Python libraries [2] [3] which would be cumbersome and much less effective in a language lacking the equivalent of Python's "with" statement.

To summarize the concurrency control structure, called a "nursery": all spawned tasks within the scope block are owned by that scope's context manager, and the scope will not end until all child tasks are completed.  If a child has an exception, all other child tasks will be cancelled and the error will be propagated.  I'm well versed in trying to use Lua function lambdas for this kind of problem.  The result is not satisfying.

Regards,
--John


Reply | Threaded
Open this post in threaded view
|

Re: (not) handling new programming idioms with grace

Pierre Chapuis
On Sun, Jul 15, 2018, at 16:22, John Belmonte wrote:
My position on Lua's need for some type of scope exit hook is only stronger these days.  It's not just about resource cleanup.  For example, there are some very interesting concurrency and cancellation control structures being developed as Python libraries [2] [3] which would be cumbersome and much less effective in a language lacking the equivalent of Python's "with" statement.

I kind of agree that something like "with" could be useful in Lua. In my opinion one way to do it would be to have a construct which forces garbage collection of the variables created when exiting the block. This way cleanup would be left to the `__gc` metamethod, but it would be deterministic. The advantage would be that it would also work with code that already uses the `__gc` metamethod as a cleanup possibility.

This syntax is probably not right but the idea is:

with
    local my_resource = acquire()
do
    stuff...
end -- resource GC'd here

One place where this could be useful is iterators. In my code base I have iterators that allocate resources that should absolutely be released after iteration, e.g. database transactions. The iterator does it after all items have been iterated, but it does not work if the calling code breaks the loop, so I have to write things like this:

    local _next, _state = some_iterator()
    for v in _next, _state do
        if some_condition then
            _state:clear()
            break
        end
    end

With that construct we let `__gc` clear the state and do this instead:

    with
        local _next, _state = some_iterator()
    do
        for v in _next, _state do
            if some_condition then
                break
            end
        end
    end

There could even be some syntactic sugar for the for loop, e.g.:

    for v with some_iterator() do
        if some_condition then
            break
        end
    end

-- 
Pierre Chapuis
Reply | Threaded
Open this post in threaded view
|

Re: (not) handling new programming idioms with grace

Nagaev Boris
In reply to this post by John Belmonte
On Sun, Jul 15, 2018 at 10:22 AM, John Belmonte <[hidden email]> wrote:

> It's been about 10 years since my post "state of the Lua nation on resource
> cleanup" [1].  The only relevant thing that's happened in this area since
> then was Lua getting pcall + coroutine love in 5.2.
>
> My position on Lua's need for some type of scope exit hook is only stronger
> these days.  It's not just about resource cleanup.  For example, there are
> some very interesting concurrency and cancellation control structures being
> developed as Python libraries [2] [3] which would be cumbersome and much
> less effective in a language lacking the equivalent of Python's "with"
> statement.
>
> To summarize the concurrency control structure, called a "nursery": all
> spawned tasks within the scope block are owned by that scope's context
> manager, and the scope will not end until all child tasks are completed.  If
> a child has an exception, all other child tasks will be cancelled and the
> error will be propagated.  I'm well versed in trying to use Lua function
> lambdas for this kind of problem.  The result is not satisfying.
>
> Regards,
> --John
>
>
> [1] http://lua-users.org/lists/lua-l/2009-01/msg00333.html
> [2]
> https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/
> [3] https://vorpus.org/blog/timeouts-and-cancellation-for-humans/
>

Hey John!

I looked through your post [2] "Notes on structured concurrency, or:
Go statement considered harmful". There is sync.WaitGroup type in Go
that allows you to make sure all launched goroutines have exited:

var wg sync.WaitGroup
for i := 0; i < 10; i++ {
  wg.Add(1)
  go func() {
    defer wg.Done()
    // do something
  }()
}
wg.Wait()

> In most concurrency frameworks, go statements cause the exact
> same problem: whenever you call a function, it might or might not
> spawn some background task. The function seemed to return, but
> is it still running in the background?

There are cases when this is a desired behavior. For example HTTP
request handler may start a backgroud task, but not wait for it to
finish.

In the section "There is an escape." you proposed to pass nursery
inside any function that may spawn goroutines. Isn't it too verbose?
In case you are troubleshooting goroutines leakage you have a lot of
tools in Go that show you how (call stacks) they were started and
where they are blocked. This issue is pretty rare from my experience.
Does it worth passing another argument into almost any function just
to cure it a bit? Go is the language of compromises (as opposed to
Rust), that is why it has GC and "go" statement out of box - it is
lesser evil. Just my few cents.

--
Best regards,
Boris Nagaev

Reply | Threaded
Open this post in threaded view
|

Re: (not) handling new programming idioms with grace

Soni "They/Them" L.
In reply to this post by Pierre Chapuis


On 2018-07-15 11:43 AM, Pierre Chapuis wrote:

> On Sun, Jul 15, 2018, at 16:22, John Belmonte wrote:
>> My position on Lua's need for some type of scope exit hook is only
>> stronger these days.  It's not just about resource cleanup.  For
>> example, there are some very interesting concurrency and cancellation
>> control structures being developed as Python libraries [2] [3] which
>> would be cumbersome and much less effective in a language lacking the
>> equivalent of Python's "with" statement.
>
> I kind of agree that something like "with" could be useful in Lua. In
> my opinion one way to do it would be to have a construct which forces
> garbage collection of the variables created when exiting the block.
> This way cleanup would be left to the `__gc` metamethod, but it would
> be deterministic. The advantage would be that it would also work with
> code that already uses the `__gc` metamethod as a cleanup possibility.
>
> This syntax is probably not right but the idea is:
>
> with
>     local my_resource = acquire()
> do
>     stuff...
> end -- resource GC'd here
>
> One place where this could be useful is iterators. In my code base I
> have iterators that allocate resources that should absolutely be
> released after iteration, e.g. database transactions. The iterator
> does it after all items have been iterated, but it does not work if
> the calling code breaks the loop, so I have to write things like this:
>
>     local _next, _state = some_iterator()
>     for v in _next, _state do
>         if some_condition then
>             _state:clear()
>             break
>         end
>     end
>
> With that construct we let `__gc` clear the state and do this instead:
>
>     with
>         local _next, _state = some_iterator()
>     do
>         for v in _next, _state do
>             if some_condition then
>                 break
>             end
>         end
>     end
>
> There could even be some syntactic sugar for the for loop, e.g.:
>
>     for v with some_iterator() do
>         if some_condition then
>             break
>         end
>     end
>
> --
> Pierre Chapuis

Or a very simple syntax sugar:

call io.openwith("/dev/null", "w")
   it:write("hello world!")
end

becomes

io.openwith("/dev/null", "w", function(it)
   it:write("hello world!")
end)

Don't use __gc. Don't rely on __gc. Ban __gc. Debug hooks can't see
__gc. __gc is a known sandbox exploit. We can't use __gc for things like
this.

Reply | Threaded
Open this post in threaded view
|

Re: (not) handling new programming idioms with grace

Dirk Laurie-2
In reply to this post by John Belmonte
2018-07-15 16:22 GMT+02:00 John Belmonte <[hidden email]>:

> It's been about 10 years since my post "state of the Lua nation on resource
> cleanup" [1].  The only relevant thing that's happened in this area since
> then was Lua getting pcall + coroutine love in 5.2.
>
> My position on Lua's need for some type of scope exit hook is only stronger
> these days.  It's not just about resource cleanup.  For example, there are
> some very interesting concurrency and cancellation control structures being
> developed as Python libraries [2] [3] which would be cumbersome and much
> less effective in a language lacking the equivalent of Python's "with"
> statement.
>
> To summarize the concurrency control structure, called a "nursery": all
> spawned tasks within the scope block are owned by that scope's context
> manager, and the scope will not end until all child tasks are completed.  If
> a child has an exception, all other child tasks will be cancelled and the
> error will be propagated.  I'm well versed in trying to use Lua function
> lambdas for this kind of problem.  The result is not satisfying.

I don't quite understand the problem, and maybe my ignorance shows,
but ...

What does a 'with' structure achieve that

repeat
  local whatever
...
  if exception then break end
...
until false

does not?

Reply | Threaded
Open this post in threaded view
|

Re: (not) handling new programming idioms with grace

Pierre Chapuis
In reply to this post by John Belmonte
> I don't quite understand the problem, and maybe my ignorance shows,
> but ...
>
> What does a 'with' structure achieve that
>
> repeat
>   local whatever
> ...
>   if exception then break end
> ...
> until false
>
> does not?

I don't really get how this is similar to "with". The goal of "with" (i.e Python Context Managers [1]) is to make sure that something is executed at the beginning of a code block and something else at the end. So it would be more something like this in Lua terms:

    with foo do
        -- stuff
    end

... works a bit like...

    do
        foo:__enter()
        -- stuff
        foo:__exit()
    end

... except `__exit` is called no matter what happens in "stuff", including all those cases:

    -- foo:__exit() is called once
    local function f(foo)
        with foo do
            return
        end
    end

    -- foo:__exit() is called twice
    for i = 1, 5 do
        with foo do
            if i == 2 then
                break
            end
        end
    end

    -- foo:__exit()  is called once
    with foo do
        error()
    end

This is important when you write code that deals with a resource that has to be released immediately and not asynchronously so you cannot rely on `__gc`, e.g. a database transaction, a mutex, arguably some file descriptors...

[1] https://docs.python.org/2.5/whatsnew/pep-343.html

Reply | Threaded
Open this post in threaded view
|

Re: (not) handling new programming idioms with grace

Dirk Laurie-2
2018-07-15 19:49 GMT+02:00 Pierre Chapuis <[hidden email]>:

>> I don't quite understand the problem, and maybe my ignorance shows,
>> but ...
>>
>> What does a 'with' structure achieve that
>>
>> repeat
>>   local whatever
>> ...
>>   if exception then break end
>> ...
>> until false
>>
>> does not?
>
> I don't really get how this is similar to "with". The goal of "with" (i.e Python Context Managers [1]) is to make sure that something is executed at the beginning of a code block and something else at the end. So it would be more something like this in Lua terms:
>
>     with foo do
>         -- stuff
>     end
>
> ... works a bit like...
>
>     do
>         foo:__enter()
>         -- stuff
>         foo:__exit()
>     end
>
> ... except `__exit` is called no matter what happens in "stuff", including all those cases:
>
>     -- foo:__exit() is called once
>     local function f(foo)
>         with foo do
>             return
>         end
>     end
>
>     -- foo:__exit() is called twice
>     for i = 1, 5 do
>         with foo do
>             if i == 2 then
>                 break
>             end
>         end
>     end
>
>     -- foo:__exit()  is called once
>     with foo do
>         error()
>     end
>
> This is important when you write code that deals with a resource that has to be released immediately and not asynchronously so you cannot rely on `__gc`, e.g. a database transaction, a mutex, arguably some file descriptors...
>
> [1] https://docs.python.org/2.5/whatsnew/pep-343.html

Thanks for explaining.

Reply | Threaded
Open this post in threaded view
|

Re: (not) handling new programming idioms with grace

Andrew Starks-2
In reply to this post by Pierre Chapuis


On Sun, Jul 15, 2018 at 12:49 Pierre Chapuis <[hidden email]> wrote:

Snip



This is important when you write code that deals with a resource that has to be released immediately and not asynchronously so you cannot rely on `__gc`, e.g. a database transaction, a mutex, arguably some file descriptors...

[1] https://docs.python.org/2.5/whatsnew/pep-343.html



What about calling collectgarnage(“collect”)?




Reply | Threaded
Open this post in threaded view
|

Re: (not) handling new programming idioms with grace

John Belmonte
In reply to this post by Pierre Chapuis
On Sun, Jul 15, 2018 at 10:43 PM, Pierre Chapuis <[hidden email]> wrote:
I kind of agree that something like "with" could be useful in Lua. In my opinion one way to do it would be to have a construct which forces garbage collection of the variables created when exiting the block. This way cleanup would be left to the `__gc` metamethod, but it would be deterministic. The advantage would be that it would also work with code that already uses the `__gc` metamethod as a cleanup possibility.

Lack of an implementation strategy is not the obstacle to getting scope hook support into the Lua language.  There were plenty of proof-of-concept implementations 10 years ago.  (Using GC is not the preferred method, but that's besides the point.)

The challenge is convincing the Lua authors that this kind of feature is worth adding to the language.
Reply | Threaded
Open this post in threaded view
|

Re: (not) handling new programming idioms with grace

Daurnimator
In reply to this post by Pierre Chapuis
On 16 July 2018 at 03:49, Pierre Chapuis <[hidden email]> wrote:

> I don't really get how this is similar to "with". The goal of "with" (i.e Python Context Managers [1]) is to make sure that something is executed at the beginning of a code block and something else at the end. So it would be more something like this in Lua terms:
>
>     with foo do
>         -- stuff
>     end
>
> ... works a bit like...
>
>     do
>         foo:__enter()
>         -- stuff
>         foo:__exit()
>     end
>
> ... except `__exit` is called no matter what happens in "stuff", including all those cases:
>
>     -- foo:__exit() is called once
>     local function f(foo)
>         with foo do
>             return
>         end
>     end
>
>     -- foo:__exit() is called twice
>     for i = 1, 5 do
>         with foo do
>             if i == 2 then
>                 break
>             end
>         end
>     end
>
>     -- foo:__exit()  is called once
>     with foo do
>         error()
>     end
>
> This is important when you write code that deals with a resource that has to be released immediately and not asynchronously so you cannot rely on `__gc`, e.g. a database transaction, a mutex, arguably some file descriptors...
>
> [1] https://docs.python.org/2.5/whatsnew/pep-343.html
>

What doesn't nicely translate to lua is what to do in the `yield` case:

local function foo()
    with bar do
        coroutine.yield(baz) -- maybe baz contains something based on `bar`
    end
end
local f = coroutine.wrap(foo)
f()
if xyz then -- only *maybe* does the coroutine get resumed
    f()
end

Reply | Threaded
Open this post in threaded view
|

Re: (not) handling new programming idioms with grace

John Belmonte
In reply to this post by Nagaev Boris

On Sun, Jul 15, 2018 at 10:46 PM, Nagaev Boris <[hidden email]> wrote:
I looked through your post [2] "Notes on structured concurrency, or:
Go statement considered harmful". There is sync.WaitGroup type in Go
that allows you to make sure all launched goroutines have exited:
... 
In the section "There is an escape." you proposed to pass nursery
inside any function that may spawn goroutines. Isn't it too verbose?

Hi Boris.  I'm not the author of that article.  It does acknowledge Go utilities for similar control structures [1].  But a big point of the article is that having ad-hoc spawning ability surfaced to the language will break the abstraction and make programs very difficult to reason about, because 3rd party code may be using those low level primitives.  In any case the article is not an attack on Go language, rather it's about evolving how we deal with concurrency in programming.

Regardless, the point of my own post was that there are compelling idioms emerging based on Python-like "with" or RAII, and they can't be implemented nicely in Lua.  The article on timeouts and cancellation I referenced is another example.



Reply | Threaded
Open this post in threaded view
|

Re: (not) handling new programming idioms with grace

Pierre Chapuis
In reply to this post by Andrew Starks-2
On Mon, Jul 16, 2018, at 03:00, Andrew Starks wrote:
What about calling collectgarnage(“collect”)?

In some system I did that in a global error handler (top-level pcall) to avoid problems. However that forces collection of all garbage, not a single object. I wouldn't do it after a for loop, for instance. Also that doesn't work (or isn't easy to write) if you call `return`.

-- 
Pierre Chapuis
Reply | Threaded
Open this post in threaded view
|

Re: (not) handling new programming idioms with grace

Dirk Laurie-2
In reply to this post by John Belmonte
2018-07-16 3:10 GMT+02:00 John Belmonte <[hidden email]>:

> On Sun, Jul 15, 2018 at 10:43 PM, Pierre Chapuis <[hidden email]>
> wrote:
>>
>> I kind of agree that something like "with" could be useful in Lua. In my
>> opinion one way to do it would be to have a construct which forces garbage
>> collection of the variables created when exiting the block. This way cleanup
>> would be left to the `__gc` metamethod, but it would be deterministic. The
>> advantage would be that it would also work with code that already uses the
>> `__gc` metamethod as a cleanup possibility.
>
>
> Lack of an implementation strategy is not the obstacle to getting scope hook
> support into the Lua language.  There were plenty of proof-of-concept
> implementations 10 years ago.  (Using GC is not the preferred method, but
> that's besides the point.)
>
> The challenge is convincing the Lua authors that this kind of feature is
> worth adding to the language.

The original post bandied Python as a language that has the desired
feature. On Ubuntu 16.04, Python 2.7 has an executable of 3492656
bytes, stripped; Python 3.5 has 4464400, ditto.

By contrast, Lua 5.3.5 has an executable of 257376 bytes, not stripped,
and Lua 5.4.0 (work2) 279400.

Let's compare the two languages on the same input.

$ lua
Lua 5.3.5  Copyright (C) 1994-2018 Lua.org, PUC-Rio
> bloat = 4464400/279400; print(bloat)
15.978525411596
$ python
Python 2.7.12 (default, Dec  4 2017, 14:50:18)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> bloat = 4464400/279400; print(bloat)
15

I'm willing to accept that the Lua authors may feel that the 'with'
feature is not important enough to 99.5% of Lua users to justify
reducing Python's bloat factor.

Reply | Threaded
Open this post in threaded view
|

Re: (not) handling new programming idioms with grace

Chris Jones
Hey

Lua has 0.978525411596 more bloats than python? ;)

Cheers,
Chris

On 16 July 2018 at 11:40, Dirk Laurie <[hidden email]> wrote:
2018-07-16 3:10 GMT+02:00 John Belmonte <[hidden email]>:
> On Sun, Jul 15, 2018 at 10:43 PM, Pierre Chapuis <[hidden email]>
> wrote:
>>
>> I kind of agree that something like "with" could be useful in Lua. In my
>> opinion one way to do it would be to have a construct which forces garbage
>> collection of the variables created when exiting the block. This way cleanup
>> would be left to the `__gc` metamethod, but it would be deterministic. The
>> advantage would be that it would also work with code that already uses the
>> `__gc` metamethod as a cleanup possibility.
>
>
> Lack of an implementation strategy is not the obstacle to getting scope hook
> support into the Lua language.  There were plenty of proof-of-concept
> implementations 10 years ago.  (Using GC is not the preferred method, but
> that's besides the point.)
>
> The challenge is convincing the Lua authors that this kind of feature is
> worth adding to the language.

The original post bandied Python as a language that has the desired
feature. On Ubuntu 16.04, Python 2.7 has an executable of 3492656
bytes, stripped; Python 3.5 has 4464400, ditto.

By contrast, Lua 5.3.5 has an executable of 257376 bytes, not stripped,
and Lua 5.4.0 (work2) 279400.

Let's compare the two languages on the same input.

$ lua
Lua 5.3.5  Copyright (C) 1994-2018 Lua.org, PUC-Rio
> bloat = 4464400/279400; print(bloat)
15.978525411596
$ python
Python 2.7.12 (default, Dec  4 2017, 14:50:18)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> bloat = 4464400/279400; print(bloat)
15

I'm willing to accept that the Lua authors may feel that the 'with'
feature is not important enough to 99.5% of Lua users to justify
reducing Python's bloat factor.




--
Cheers,

Chris
Reply | Threaded
Open this post in threaded view
|

Re: (not) handling new programming idioms with grace

Viacheslav Usov

On Mon, Jul 16, 2018 at 12:46 PM Chris Jones <[hidden email]> wrote:

> Let's compare the two languages on the same input.

This is utterly nonsensical.

Cheers,
V.
Reply | Threaded
Open this post in threaded view
|

Re: (not) handling new programming idioms with grace

Pierre Chapuis
In reply to this post by Daurnimator
On Mon, Jul 16, 2018, at 03:17, Daurnimator wrote:

> What doesn't nicely translate to lua is what to do in the `yield` case:
>
> local function foo()
>     with bar do
>         coroutine.yield(baz) -- maybe baz contains something based on `bar`
>     end
> end
> local f = coroutine.wrap(foo)
> f()
> if xyz then -- only *maybe* does the coroutine get resumed
>     f()
> end

I was unsure how that was dealt with in Python. This code:

    class Foo(object):

        def __init__(self):
            pass

        def __enter__(self):
            print("enter")
            return self

        def __exit__(self, *args):
            print("exit")

    foo = Foo()

    def my_gen_f():
        while True:
            with foo:
                yield True

    def f():
        my_gen = my_gen_f()
        next(my_gen)
        print("after")

    f()

    print("finally")

prints:

    enter
    after
    exit
    finally

This is unrelated to the GC, disabling it does not change the output.

Reply | Threaded
Open this post in threaded view
|

Re: (not) handling new programming idioms with grace

Andrew Starks-2
In reply to this post by Pierre Chapuis


On Mon, Jul 16, 2018 at 4:02 AM, Pierre Chapuis <[hidden email]> wrote:
On Mon, Jul 16, 2018, at 03:00, Andrew Starks wrote:
What about calling collectgarnage(“collect”)?

In some system I did that in a global error handler (top-level pcall) to avoid problems. However that forces collection of all garbage, not a single object. I wouldn't do it after a for loop, for instance. Also that doesn't work (or isn't easy to write) if you call `return`.

-- 
Pierre Chapuis


I remain curious. Has this been tested and found too slow before?

I had a similar concern with file handles in a media playback system and I tried out two things that seemed to work. I did not do any extensive performance testing because everything we "fast enough" for what I was doing.

The first thing I did was run the GC after the section where I had opened it, using pcall to test for success.

The second thing I did was run the GC manually on every frame. This was simplest and worked great but is not practical for other applications.

I realize that making *sure* that you run GC in the event of failure can be tricky. You also have to make sure that you don't have any external references (or use week values). Given that this is the way in which Lua releases resources, and that the GC runs on its own anyway, it seems like this would be the path of least resistance and likely not *that* slow.


--
Andrew Starks
Reply | Threaded
Open this post in threaded view
|

Re: (not) handling new programming idioms with grace

Dibyendu Majumdar
In reply to this post by John Belmonte
Hi,

On 15 July 2018 at 15:22, John Belmonte <[hidden email]> wrote:
> It's been about 10 years since my post "state of the Lua nation on resource
> cleanup" [1].  The only relevant thing that's happened in this area since
> then was Lua getting pcall + coroutine love in 5.2.
>
> [1] http://lua-users.org/lists/lua-l/2009-01/msg00333.html

I don't believe it is technically possible to implement deterministic
cleanup of objects in Lua. I think the main issue is Lua's approach of
throwing exceptions using longjmp. As far as I know, you need
systematic stack unwinding in order to implement something like this -
and that would be impossible to do while keeping Lua's primary design
criteria - to be small and portable.

If you have a technical solution that works - or if anyone else has -
would be happy to be corrected.

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: (not) handling new programming idioms with grace

Roberto Ierusalimschy
> I don't believe it is technically possible to implement deterministic
> cleanup of objects in Lua. I think the main issue is Lua's approach of
> throwing exceptions using longjmp. As far as I know, you need
> systematic stack unwinding in order to implement something like this -
> and that would be impossible to do while keeping Lua's primary design
> criteria - to be small and portable.
>
> If you have a technical solution that works - or if anyone else has -
> would be happy to be corrected.

We do. All this has been discussed some time ago; see [1].
(BTW, you brought the same issue to that thread, and you got the
answer there :-)

However, a main issue of any "deterministic cleanup" in Lua is its
interaction with coroutines. A coroutine can enter a block and never
leave it.

[1] http://lua-users.org/lists/lua-l/2015-11/msg00303.html

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: (not) handling new programming idioms with grace

Dibyendu Majumdar
Hi Roberto,

On 16 July 2018 at 18:54, Roberto Ierusalimschy <[hidden email]> wrote:

>> I don't believe it is technically possible to implement deterministic
>> cleanup of objects in Lua. I think the main issue is Lua's approach of
>> throwing exceptions using longjmp. As far as I know, you need
>> systematic stack unwinding in order to implement something like this -
>> and that would be impossible to do while keeping Lua's primary design
>> criteria - to be small and portable.
>>
>> If you have a technical solution that works - or if anyone else has -
>> would be happy to be corrected.
>
> We do. All this has been discussed some time ago; see [1].
> (BTW, you brought the same issue to that thread, and you got the
> answer there :-)

Indeed this was discussed before - I thought then and now the problem
is that deterministic cleanup is difficult when errors are thrown. I
do not recall seeing a solution to that - I re-read your replies just
now, and the solution did not stand out to me.

> However, a main issue of any "deterministic cleanup" in Lua is its
> interaction with coroutines. A coroutine can enter a block and never
> leave it.
>

I am not sure that this is a problem ... at least if we are talking
about the same thing.
In languages where you have a 'finally' block - the block only
triggers if the stack unwinds through it. If you start some other
thread and that thread never returns back to the same stack then the
finally would never run.

Regards
Dibyendu

12345