It was thus said that the Great Archie Cobbs once stated:
> On Sun, Jan 26, 2020 at 8:42 PM Sean Conner <sean@conman.org> wrote:
>
> > Oh, so I have to rewrite code to use the new names (or a preprocessor
> > hack).
>
> Sort-of. Here's how I would propose we approach this.
>
> STEP 1: Add a new header "lnbposix.h" to Lua.
[ snip ]
> For now, "lnbposix.h" will simply contain the following definitions:
>
> #define luaNB_read read
> #define luaNB_write write
> #define luaNB_nanosleep nanosleep
> ...etc...
Yes, the preprocessor hack I mentioned.
There are problems with this (in general, not with the preprocessor hack):
1. It adds a dependency to Lua, namely GNU pth.
I'm not proposing that for Lua itself right now. I'm simply proposing we add the header with the #defines:
Absolutely nothing will change in Lua itself.
The idea is that this header file allows Lua hackers to create future variants of Lua that support non-blocking, and at the same time allows C module hackers to create Lua modules that work properly with those variants (when they arrive) and yet also remain backward compatible with "plain" Lua.
2. GNU pth is LGPL.
This is an orthogonal issue and can be sorted out later, at worst, by writing a new implementation of the same thing from scratch.
But in any case that's all in the future, pending further discussion. It doesn't stop going ahead and laying the groundwork now with a simple header file.
For now all I want is to start letting C module writers convert their code from read() to luaNP_read() today so they are ready for non-blocking support, whatever form it may take, if/when it occurs sometime in the future.
3. The elephant in the room---Windows.
For any particular feature, either the platform supports it or the platform does not. That's true of any feature.
If Windows supports non-blocking versions of read(), write(), etc. somehow, then it can be done. If not it can't and so you'd necessarily fall back to "blocking" Lua.
5. You'll need to patch os.system() and most of io in stock Lua to use this
as well, which is a tall order. While select() et al. are used on file
descriptors, not every file descriptor can be meaningfully used with
it---notably real files will always return a ready status, even if the files
are on a exceedingly slow floppy drive! But there are some devices (like
serial ports or the current TTY) that can, and they can be opened via
io.open(). [1]
Yes, to the extent Lua libraries use any blocking POSIX calls, they would also need to be updated like any other C code. It's a simple find & replace.
This doesn't seem very complicated or controversial to me. It's adding a lightweight wrapper layer to allow for very desirable future functionality (namely, composable modules that also support non-blocking coroutines), and has zero runtime cost for current ("plain" Lua) implementations.
Is there some Lua authority out there who can provide feedback on this idea? How are Lua patches supposed to be reviewed around here?
-Archie
Archie L. Cobbs
