> > What functions would those be? Because there's this other thread trying
> > to define a minimal set of "batteries" for Lua ...
>
> Here are the POSIX functions that pth provides wrappers for:
>
> pth_nanosleep, pth_usleep, pth_sleep, pth_waitpid, pth_system, pth_sigmask,
> pth_sigwait, pth_accept, pth_connect, pth_select, pth_pselect,
> pth_poll, pth_read,
> pth_readv, pth_write, pth_writev, pth_pread, pth_pwrite, pth_recv, pth_recvfrom,
> pth_send, pth_sendto.
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.
The name "lnbposix" stands for "Lua non-blocking versions of POSIX functions".
The meaning of this file is basically this:
If you are writing a C module and are using any blocking POSIX
system calls, and you want your code to be automatically compatible
with a possible future version or variant of the Lua runtime that
supports yielding coroutines when they make blocking calls, then
you can use these functions in place of the normal POSIX functions
and everything will work out great either way.
There could eventually be other header files for non-POSIX blocking functions as needed.
For now, "lnbposix.h" will simply contain the following definitions:
#define luaNB_read read
#define luaNB_write write
#define luaNB_nanosleep nanosleep
...etc...
So far, nothing functions differently, but your module is now "non-blocking ready".
Because this file has no effect, it can be included in even "plain" Lua distributions.
The semantics of function luaNB_foo() would be defined to be the same as foo(), with the exception that luaNB_foo() may cause the coroutine to yield IF that is supported on the current platform. If not, it behaves exactly like foo().
STEP 2: Argue about where and how we should implement real, non-blocking versions of luaNB_read(), luaNB_write(), etc. :)
Is this something we could get added to version 5.4??
-Archie
--
Archie L. Cobbs
