I/O redirection requires call to Connection.__handle()

[axw]

Presently the I/O redirection in the server-side of a Pushy connection will make calls to the client's sys.stdout/sys.stderr write() methods. This is a standard proxy object method invocation, and so requires that the client be invoking "__handle()" to handle a message.

The need to continuously handle messages is made apparent when the captured output is written back to the client after the command is invoked. For example, if a client calls subprocess.Popen(...), the call will complete but output may be generated afterwards.

---

Imported from Launchpad using lp2gh.

• date created: 2008-10-24T02:10:01Z
• owner: axwalk
• assignee: axwalk
• the launchpad url was https://bugs.launchpad.net/bugs/288489

[axw]

(by axwalk) The solution should be to put the responsibility of polling output on the client.

The server will capture stdout/stderr, and store it locally. The client will periodically request for the outstanding captured stdout/stderr. These requests will be performed in a background thread.

[axw]

(by axwalk) Scratch that - the solution should be to have the client process requests in the background, which will allow requests to come from the server asynchronously. This will require the fewest changes to how Pushy currently works, and ensure prompt display of I/O (and handling of other asynchronous requests).

[axw]

(by axwalk) Some fairly major changes have been made to fix this defect, and to support asynchronous requests in general. Essentially, the changes boil down to having a background thread on the client receive requests from the server, where those requests aren't the result of a request from the client (dubbed a synchronous request, or "syncrequest").

These changes exposed a problem in Windows: a blocking read on stdin, where stdin is a pipe (e.g. with the "local" transport), may stop other low-level Windows API calls from proceeding. For example, a call to LoadLibrary may be blocked while attempting to read from stdin when the peer is not ready to write anything to the pipe. This was leading to deadlocks in Pushy on Windows. The solution to this problem was to disallow reading from the peer when a request is being processed, unless that request is performing a syncrequest.

We now have a background thread that waits for messages, and passes them off to the relevant thread (background request thread, or a thread waiting for a response.)