This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Win PTY library.


On 9/17/12 6:48 AM, Christopher Faylor wrote:
> On Mon, Sep 17, 2012 at 03:42:14PM +0200, V??clav Zeman wrote:
>> On 17 September 2012 15:27, Charles Wilson wrote:
>>> Well, that's exactly what Console2 does, and it works pretty well.
>>> I've never seen any "missing" data when using it.  I don't know what
>>> they're doing to work around the deadlock issue, but whatever it is it
>>> works.

As I can tell from reading the code, Console2 is still just polling
and scraping. The specific deadlock I mentioned doesn't matter if you
don't use the console accessibility APIs, which don't appear
particularly useful in any case.

>> I think that the difference is that PTY is a stream of commands that
>> get interpreted, OTOH, polled Windows console can provide only a
>> snapshot at some point in time.  It seems that it would be hard to
>> produce faithful stream of commands from this console snapshot.
>> Because Console2 is only visualizing the snapshot in its own GUI
>> window, it does not matter that it is doing that by snapshotting the
>> hidden console.  But for the PTY abstraction, a faithful chain of
>> commands seems necessary.  I think that any such polling based
>> implementation could miss some transitions in the PTY state in between
>> the polls.
> 
> I don't see why this matters more for a pty than for Console2.

I expect expect(1) to work for a general-purpose pty. Building into
Cygwin a pty layer that's based on lossy scraping of Windows consoles
is a bad idea. I expect more from the pty layer than from a tool (like
Console2) designed exclusively for human consumers.

If Cygwin adopts such a thing, I'll disable it in configuration. If I
can't do that, I'll hack it out of the code, and if I can't do that,
I'll use the last Cygwin snapshot without the change until its host
operating system falls out of support.

If you really want to emulate consoles, the right thing to do is to
hook the console APIs globally. That way, console operations are
synchronous, fast, and correct, and any program into which the hook
can't be injected could just fall back to today's pipe-based approach.

> But, rather than theorize that this doesn't work why not just point to
> code to prove it?  These kind of discussions don't have to be opinions
> thanks to the wonders of open source.

If your pty layer refreshes every 100ms and your program updates at
20, 40, and 80ms, you'll lose all but the last update. I'm not
interested in writing a testcase to demonstrate a perfectly
foreseeable problem.

Attachment: signature.asc
Description: OpenPGP digital signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]