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: Problem with select() on console

On 15 July 2010 12:57, Cliff Hones 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.
> 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).

You could disable terminal line editing (with tcsetattr) and do the
line processing yourself, or let the readline library do it all for
you, which your users would proabably appreciate anyway. Readline's
"Alternate Interface" allows you to interleave line input with other
I/O. See

I suspect readline() is the reason why this hasn't come up more frequently.


Problem reports:
Unsubscribe info:

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