Re: Blocking calls and module composability

[Sean Conner <sean@...>]

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.  Right now, Lua only has one
dependency, and that's the standard C library, which if you are compiling
Lua, you already have.

2. GNU pth is LGPL.  There is a sizable segment of the industry that avoids
anything to do with the GNU.  While there are a number of programmers who
dislike that license, there are some very large companies that actively
avoid any license with the letters G, P, and L in them.  Two in particular
are Google and Apple, which now have a lock on the future of computing
(smart phones and touch pads----seriously, that's the way the industry is
headed for home computing, sad as that is).  If you want Lua to gain
traction, this is NOT the way to go (and I'm saying this as someone who only
uses the GNU licenses).

3. The elephant in the room---Windows.  It *has* been tested with Windows
using Cygwin, which now adds an additional dependency to that platform. 
Also, it should be noted that getting C-based modules compiled and working
for Windows is problematic and there have been multiple attempts over the
years to get a working distribution for Lua for Windows (although I may be
overstating the problem here---I don't know as I tend to ignore Windows;
others can probably fill you in on the details).

4. The last release was in June of 2006.  That in and of itself doesn't mean
it doesn't work, but again, there is a segment of the industry that will
conclude that the project is dead and should be avoided.  Also, POSIX has
been updated since 2006, so at the very least, it might be outdated.  Also,
the mailing list last saw activity in June of 2012.  Again, not a good sign.

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]

> STEP 2: Argue about where and how we should implement real, non-blocking
> versions of luaNB_read(), luaNB_write(), etc. :)

  It's hard enough getting "batteries" defined for Lua.

> Is this something we could get added to version 5.4??

  I would be surprised if this came out for Lua 5.4.

  -spc

[1]	My own select() et al. wrapper can handle files opened by io.open(),
	but I do have to monkey patch the file object metatable to add a
	function to get the underlying file descriptor.  I have a similar
	function for my socket library, so the select() driver doesn't have
	to know the details of the userdata it receives---it just knows to
	call a special function to get what it needs for the select() et al.
	call.