X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-1.6 required=5.0	tests=AWL,BAYES_00
X-Spam-Check-By: sourceware.org
Message-ID: <4C3EF7BB.4040204@hones.org.uk>
Date: Thu, 15 Jul 2010 12:57:47 +0100
From: Cliff Hones <cliff AT hones DOT org DOT uk>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Problem with select() on console
References: <4C3E59E3 DOT 4050003 AT hones DOT org DOT uk> <20100715054952 DOT GB10561 AT trixie DOT casa DOT cgf DOT cx>
In-Reply-To: <20100715054952.GB10561@trixie.casa.cgf.cx>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: -0.0 (/) (dominator.watchfront.net.uk)
X-Spam-Report: dominator.watchfront.net.uk has scanned this email for spam. Results:-	T_RP_MATCHES_RCVD=-0.01 (total -0.0, current threshold 4.0)
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Christopher Faylor wrote:
> On Thu, Jul 15, 2010 at 01:44:19AM +0100, Cliff Hones wrote:
>> When select() is used to test for input availability on the standard
>> cygwin console in normal (cooked) mode, it indicates input is available
>> as soon as any key is pressed.  However, a call to read(0,...)
>> will (correctly) block until a terminating RETURN is entered.
>>
>> select() should only indicate input is available when a call
>> to read would *not* block - ie when a read call will immediately
>> return at least one character or an error such as EOF.
>> ...
> 
> Since, AFAIK, Windows has no way to do this, I don't see how it could be
> done easily.  You could, I guess, pull characters into a buffer until a
> newline was found but that would be pretty error-prone and any use of
> select() would potentially invalidate console i/o for subprocesses.
> 
> So, I don't see this changing anytime soon.

Hmm.  Having looked further, it's not just select() which is affected.
If you set the NONBLOCK flag on the console, and perform a read(),
you get error EWOULDBLOCK/EAGAIN until a key is hit.  When a key
is hit, the read blocks until RETURN is entered.

I must look at the console source - but it seems from behaviour and what
you are saying that Windows provides a way for the user to determine that
console input has started (since read() and select() behaviour changes
when a key is pressed) but no way to determine in advance that a call
to input a complete line will block because an incomplete line is present.

I'm surprised this hasn't come up more frequently.  In my case, I have an
app which needs to respond to user input line-based commands, but also
does other processing.  I don't want the app to block every time the user
starts to enter a command.  Of course I could use threads, but that's
an unnecessary change (at least unnecessary on Linux etc).  And I could
insist users use mintty, but that's rather presumptuous.

-- Cliff

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple