 |
lua-l archive |
|
|
||
|
2. Provide for a "peek" method which portably allows you to see whether a read is going to block.
And how do you "peek" into stdio's input buffer?
I meant a function to allow the caller of Steve's popen2() to set a timeout on reading data coming back from the subprocess. So I'm not sure why I'd need to do a non-blocking read on stdio to provide the incomplete but nevertheless useful "peeking" I had in mind. (I'm not sure how you tell whether a Windows pipe will block if you _write_ to it, if indeed you can.)
The idea is simply to permit a Lua program waiting for results coming back from a ubprocess to exit gracefully if the subprocess hangs, or if it itself unexpectedly blocks waiting for input (a "protocol mismatch", if you will).
This has been the most likely reason for a deadlock in my experience of using something like GAWK's "|&" (which is available on Unix only, implemented in the style of Steve's Linux code). The subprocess pops up an unexpected request for input (e.g. "Oops, do you want to continue" because you failed to make it entirely non-interactive), or simply blocks itself waiting for some other event of its own interest (e.g. waiting on /dev/random). This risk is worth taking for simple scripting, and well wroth taking if you can say "give up waiting for the subprocess after, say, 120 seconds."
As for glib's popen2()-flavoured solution -- anything which uses select() isn't portable to Windows.
The "listen" option in Netcat for Windows has a solution which IIRC is like the one Steve himself posed, using several threads and SendMessage() calls to proxy [?] data between a connected socket and a subprocess (inetd style). This code was, in its turn, lifted from a Windows port of rlogind, if I remember the comments correctly.