Re: io.popen read and write, again

[Sean Conner <sean@...>]

It was thus said that the Great Jay Carlson once stated:
> 
> The interesting problem is to allow arbitrary Lua pipeline members to have
> access to globals. The easy thing to do for pipeline members is fork(),
> but that breaks the code fragment above. The table named "list" remains
> empty.
> 
> As you're about to point out, this is not a problem in this particular
> example. It isn't for any pipeline with exactly one Lua function source or
> one Lua function sink. You can't popen a process for both reading and
> writing, 

  Well, you *can* [1], but it's hard to do, very fragile, and really not
worth it.

> so you can't build general pipelines with Lua intermediates with just
> popen().

  But you can if you wrap pipe() [2].

> The big reason you can't popen a process for both reading and writing is
> probable deadlock with blocking I/O primitives. 

  Erm ... kind of, yeah, maybe not ... [1].

> It's not a problem with independent processes hooked together by pipe(),
> and that's because Unix's design is just magic. You don't need
> non-blocking I/O and select() until you get to this kind of tricky,
> deadlock-y case. Unix was not designed for in-process coroutines.

  You can do it (in Lua, even in C) but it does get somewhat messy.

> Signal handling seems like the other looming disaster for this edition of
> /usr/bin/luash (PowerShell meets /usr/bin/es?) but it probably seems that
> way to me because I'm rusty on how shells implement signal handling.

  Signals in Unix are, in general, a disaster.

  -spc

[1]	http://lua-users.org/lists/lua-l/2014-04/msg00911.html

[2]	https://github.com/spc476/lua-conmanorg/blob/master/src/fsys.c#L624