Re: "The Evolution of Lua" -- born 1993, based on "ANSI C" -- and its relation to atomics -- 2011

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

On Thu, May 21, 2020 at 8:51 PM sur-behoffski
<sur_behoffski@grouse.com.au> wrote:

>         [1] Actually, Lua is implemented in “clean C”, that is, the
>             intersection of C and C++.  Lua compiles unmodified as a
>             C++ library.

I will argue that this is not technically correct today. Lua source
code has parts that are C++ that cannot be compiled as C. It relies on
the preprocessor and user-defined macros to select what code is
included at the compile time. Likewise, some of its "pure C" code goes
clearly beyond pure ANSI C library facilities.

> By gradually reducing the dependency of Lua’s core on the standard
>         C library, we are moving towards a Lua core that requires
>         only a free-standing ANSI C implementation.

This is probably true, but this Lua core would have lesser
functionality than what it offers in less restricted environments,
such as Posix.

My point is that Lua has already faced and accepted the reality that
it should rely upon and offer a little more than just "ANSI C" when
this is possible. Therefore it should not reject modern concurrency
mechanisms when they are available. To be clear, I am quite happy with
the fact the Lua is mostly agnostic about concurrency. However, it
needs concurrency for one feature, which is the ability to interrupt
itself asynchronously. And I think it deserves the best when it is
available.

> My reason for entering was that I believed that people were focussing
> on simple-concurrency-model race conditions, whereas modern
> multi-core architectures, with multiple level of caches, meant that
> programmers needed to be more sophisticated in dealing with
> concurrency issues in multi-threaded, shared-memory code... and that
> is what the first LWN.net article I mentioned tackled.

Your concern was certainly not ungrounded. However, the first article
that you referenced was very misleading at least in the Lua list. In
fact, even in a Linux kernel list I would find it misleading: if it
assumes that the readership knows why C11 atomics were not relevant
for the Linux kernel development, the subject and content of the
article should be trivial for the intended audience.

The articles you referenced in your second post would again be
meaningful to a person with interest in the Linux kernel development,
but, again, very likely confusing outside that niche.

Cheers,
V.