terminal
terminal copied to clipboard
microsoft
ConPTY host lingers when all connected clients have been terminated
Description of the new feature/enhancement
On POSIX systems the master end will receive an EOF when all processes that use the slave have terminated or closed the connection. With ConPTY this does not appear to happen, as the pty handling process continues running (and could be used to start new processes). Closing the ConPTY will generate an EOF, but also terminate any remaining processes and possibly lose pending output.
Currently a master that does a blocking read from a ConPTY pipe will hang indefinitely when all slaves have terminated.
Proposed technical implementation details (optional)
Suggestion:
Add an API call to check whether a ConPTY is idle and has no active clients or pending data, and thus is safe to close, or in the alternative add an API call to ask the ConPTY to terminate as soon as its client count reaches zero and not output is pending.
So, funny enough, this is actually supposed to work properly. The handles servicing the PTY should get EOF when the last connected application goes away. We recently made some changed in this area (can't find the bug/PR right now) that resulted in significantly more regressions than we were comfortable with, but it's definitely on our radar.
Thanks!
Shortest possible version of the explanation: the pty host is holding a ConDrv device reference handle, and conhost thinks there's still a client connected because of it. :smile:
This is going to have to be fixed at the same time as #1810. /cc @miniksa; i've triaged this into the same milestone at 1810.
This seems to me to have the potential for a race condition when starting multiple short-lived processes on the same ConPTY. I guess you could start a long-lived process (eg hanging on a read on a stdin pipe) first, and then the payload processes, and then terminating the first process by closing its stdin.
As I understand it's not yer resolved, right?
But what is the proper way to read all output of a process then? As if we will continuously read eventually we will block.
Thank you
:tada:This issue was addressed in #14544, which has now been successfully released as Windows Terminal Preview v1.17.1023.:tada:
Handy links:
