Why should not toclose be the default?

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

Why should not toclose be the default?

Dirk Laurie-2
Is there any good, sound reason why a local variable needs to remain
in limbo after it has gone out of scope?

If not, we don't need <toclose> at all.

Reply | Threaded
Open this post in threaded view
|

Re: Why should not toclose be the default?

Jim-2
23.06.2019, 13:59, "Dirk Laurie" <[hidden email]>:
> Is there any good, sound reason why a local variable needs to remain
> in limbo after it has gone out of scope?

wasn't it more about the underlying resources than about variables ?


Reply | Threaded
Open this post in threaded view
|

Re: Why should not toclose be the default?

Michal Kottman
In reply to this post by Dirk Laurie-2
You would need a different "keyword" to mark the intent to "leak" the resource. Hypothetical current-Lua code:

function sandbox.open(filename)
  assert(checkpath(filename))
  local f = assert(io.open(filename))
  -- some other processing on f
  return f
end
Reply | Threaded
Open this post in threaded view
|

Re: Why should not toclose be the default?

Dirk Laurie-2
Op So. 23 Jun. 2019 om 14:09 het Michal Kottman <[hidden email]> geskryf:
>
> You would need a different "keyword" to mark the intent to "leak" the resource. Hypothetical current-Lua code:
>
> function sandbox.open(filename)
>   assert(checkpath(filename))
>   local f = assert(io.open(filename))
>   -- some other processing on f
>   return f
> end

Intent to "leak"? Unless these words are unhappily chosen, it sounds
like a lurking bug factory.

Reply | Threaded
Open this post in threaded view
|

Re: Why should not toclose be the default?

Viacheslav Usov
In reply to this post by Dirk Laurie-2
On Sun, Jun 23, 2019 at 1:59 PM Dirk Laurie <[hidden email]> wrote:
Is there any good, sound reason why a local variable needs to remain
in limbo after it has gone out of scope?

Not the variable, but the value that it has.

If the value has made its way into an upvalue, a table or something else that made its lifetime non-local, closing it upon its leaving the local scope might be premature.

I have advocated the use of reference counting as a way to make this whole issue more or less taken care of automatically and with minimal impact on existing Lua code and libraries.

Cheers,
V.

v
Reply | Threaded
Open this post in threaded view
|

Re: Why should not toclose be the default?

v
In reply to this post by Dirk Laurie-2
On Sun, 2019-06-23 at 13:59 +0200, Dirk Laurie wrote:
> Is there any good, sound reason why a local variable needs to remain
> in limbo after it has gone out of scope?
>
> If not, we don't need <toclose> at all.

Thing is, variable != value. <toclose> is about closing variable when
it leaves scope, not to make garbage collector removing variable when
it have no more refs immediately.

I look at this as an attempt to add RAII support to Lua without
seriously breaking exsisting code. For example:

function processFile(fname)
  local <toclose> f = assert(io.open(fname, 'r'))
  ... perform operations ...
  return textProcessed
end

When function exit (by any means, eiter return or error), file will be
closed without need to do so manually or waiting for GC.

However, this example is different:

function extractFile(archive, archpath)
  local <toclose> archfile = assert(io.open(archive, 'r'))
  ... extract file ...
  local file = assert(io.open(tmppath, 'r'))
  ... some checks/cleanup ...
  return file
end

Here we want to return file and don't want to close it when we exit the
function by returning it, so <toclose> doesn't fit our needs. (Strictly
speaking, that still would be great to close it if checks caused an
error, but this introduce some overhead):

...
  local <toclose> file = assert(io.open(tmppath, 'r'))
  ... some checks/cleanup ...
  local retfile = file
  file = nil
  return retfile
end

If you're familiar with C/C++, you probably may think about <toclose>
variables as a stack ones. If you return it by value, you'll be fine.
But if you return it as reference, you'll get invalid results (less
dramatic than in C/C++, but still).

One limitation here is that in Lua define what is passed by reference
(functions, tables, userdatas) and what does not (everything else).


Reply | Threaded
Open this post in threaded view
|

Re: Why should not toclose be the default?

Jim-2
In reply to this post by Viacheslav Usov
23.06.2019, 14:41, "Viacheslav Usov" <[hidden email]>:
> I have advocated the use of reference counting as a way to make
> this whole issue more or less taken care of automatically and with
> minimal impact on existing Lua code and libraries.

i also wondered wether support for reference counting (via the C API)
in cases the programmer sees fit might be useful ?


Reply | Threaded
Open this post in threaded view
|

Re: Why should not toclose be the default?

Rodrigo Azevedo
In reply to this post by Dirk Laurie-2
Em dom, 23 de jun de 2019 às 08:59, Dirk Laurie
<[hidden email]> escreveu:
>
> Is there any good, sound reason why a local variable needs to remain
> in limbo after it has gone out of scope?
>
> If not, we don't need <toclose> at all.

Overhead? Lua is also about performance.

Let's work the problem from scratch: Lua has 'local variables' that are ordered
local x,y = ...
local z = ...
They also have well defined 'lifetime', namely, they are lexically scoped and we
can use these properties to help us, which is the '<toclose>' (a bad
'word' choice) intent.

If you are supposing that the additional overhead from the compiler
and virtual machine to
check every 'out of scope' 'local variable' for a respective
'__toclose' method worth the
price, for me at least, it is an absolute win and must be included as
a default behavior.

Then, no more  <toclose> or <const> dicussions for the moment.

Thanks!

--
Rodrigo Azevedo Moreira da Silva