Re: Can't interrupt tight loops in Lua 5.4 anymore?

[Viacheslav Usov <via.usov@...>]

On Mon, May 25, 2020 at 8:50 PM Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:

> There was never any such guarantee in 5.3

Moreover, "Lua [..] is provided [...] with no guarantees" per the
official documentation. Therefore, whatever the official documentation
says or does not say should not matter in practice. lua_sethook() may
work in an arbitrary way, may not work at all, or may not even exist.
All in perfect accord with the official documentation.

> not part of the official documentation.

Which says: "Like any other reference manual, this document is dry in
places." Which means that it recognizes that not everything is
documented, but not all of that is really undefined behavior, i.e.,
that some of the undocumented behaviors may actually be correct or
incorrect, and Lua users may discover correct behaviors in some other
way, and have expectations based on that. But then, of course, "no
guarantees", and that does not matter.

I cannot take this "no guarantee" and "official documentation" talk
very seriously. The serious thing here is that a crucially important
aspect of Lua is undocumented, and the general attitude toward it
seems, well, pretty strange.

I am not talking about the real or imaginary problem from which this
thread started. I am talking about a simple fact: in year 2020 as well
as in year 2000, any serious user of Lua often needs a way to
interrupt a running Lua VM, asynchronously, i.e., from a signal
handler or another thread. The standalone Lua interpreter, which has
been doing just that since said year 2000, demonstrates this
convincingly. This, of course, should not mean that lua_sethook()
should be the means toward the need. I, for one, would prefer
something else, which does only one job: the interruption. Whatever
the means is, Lua NEEDS such a means, and it NEEDS to be documented as
such, with limitations if any (see below).

And this is not difficult. Since 2011 both standard C and standard C++
can do the job. Why not just use what the standards offer?  A patch
submitted by Joseph C. Sible shows exactly how this can be done. The
official documentation can state concisely that the means is
conditional on the availability of and the compliance with the
standard C or C++ atomics library. If a platform does not have that,
well, at least it is clear to the user something needs to be done.

It would be my pleasure to help with any of that, except I think
Joseph has already done all the work.

Cheers,
V.