Enable I/O communication via TCP

[andfoy]

Thanks for your great work on winpty, we have implemented a Python wrapper (pywinpty) around libwinpty that uses standard Windows pipes to communicate with winpty-agent processes. So far, we have implemented a web console for Spyder IDE (spyder-terminal) that communicates successfully with different Windows console processes.

However, other fork projects such as win-tornado-terminals might require a socket notification system, similar to file descriptors on *nix systems. AFAIK Windows does not provide socket signaling on pipes and files, which may oblige to use plain TCP sockets that have this functionality. I wonder if it's possible to adapt winpty I/O pipes to use TCP sockets instead of named pipes.

[rprichard]

In principle, I think winpty using TCP is possible. I don't think I'll add it soon. I suppose win-tornado-terminals would be happy if winpty-agent.exe started TCP server(s).

I think I'd prefer it if you found a way to use named pipes with Tornado somehow.

Aside: the pywinpty read function has this comment:

Note: This method is not fully non-blocking, however it
behaves like one.

From the caller's point-of-view, it is non-blocking, I think? With Unix-style non-blocking I/O, though, there's also select that blocks on all FDs of interest. I suppose the pywinpty caller is required to poll for I/O.

[andfoy]

Thanks for the response @rprichard, right now we're starting a periodic callback that polls a pipe to see if there's new information, that's why is non-blocking from the caller point-of-view, however we use a blocking read function. So should we stick with this solution by now?

[andfoy]

@rprichard We managed to wrap winpty calls using a socket directly on Python. I think we can close this one, unless you want to implement this feature later on.