Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
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
To: cygwin AT cygwin DOT com
From: Jason Curl <j DOT m DOT curl AT optusnet DOT com DOT au>
Subject: Re: select() read() and write() on /dev/console
Date: Tue, 23 Nov 2004 10:14:10 +0000 (UTC)
Lines: 76
Message-ID: <loom.20041123T104318-108@post.gmane.org>
References: <Pine DOT LNX DOT 4 DOT 44 DOT 0411191834400 DOT 1687-100000 AT centurai DOT sps DOT mot DOT com> <20041119183842 DOT GB26102 AT trixie DOT casa DOT cgf DOT cx> <loom DOT 20041122T151333-846 AT post DOT gmane DOT org> <20041122160636 DOT GC31237 AT trixie DOT casa DOT cgf DOT cx> <loom DOT 20041122T181615-30 AT post DOT gmane DOT org> <20041122174819 DOT GB32063 AT trixie DOT casa DOT cgf DOT cx>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet AT sea DOT gmane DOT org
X-Gmane-NNTP-Posting-Host: main.gmane.org
User-Agent: Loom/3.14 (http://gmane.org/)
X-Loom-IP: 62.180.53.223 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0)
X-IsSubscribed: yes

Christopher Faylor <cgf-no-personal-reply-please <at> cygwin.com> writes:

> 
> On Mon, Nov 22, 2004 at 05:18:46PM +0000, Jason Curl wrote:
> >Where is fds[0] defined, so I can see exactly what functions are being
> >called by peek_console, etc.?  e.g.  fh->get_readahead_valid();
> >fh->bg_check(SIGTTIN).
> 
> Also in dtable.cc.  Look for the obvious.
> 
> 

I can't build cygwin from work, and I can't download the sources by CVS
(firewall). I downloaded the sources from home, but bringing them to work
doesn't compile (the compile at home, but I don't have the test setup at home
to do this test).

The behaviour seen is
---------------------
When running strace:
- Pressing a key on the console doesn't get caught by select() very often
- When it was caught, the very first instance provided that select() said there
was data to read from fd 0, but a read returned EAGAIN/EWOULDBLOCK.

When not running strace:
- The key is caught much more often by select()
- There is a high chance when EAGAIN/EWOULDBLOCK is returned by read()

Analysis
--------
Looking at the strace logs, I see only one instance when select() set the bit
for FD 0. In this one instance read() returned EAGAIN/EWOULDBLOCK.

01 128 cygwin_select: 4, 0x22EF48, 0x22EF40, 0x22EF38, 0x22EF50
02 128 dtable::select_read: /dev/console fd 0
03 128 dtable::select_write: /dev/console fd 1
04 128 dtable::select_read: /dev/com2 fd 3
05 128 cygwin_select: to->tv_sec 5, to->tv_usec 0, ms 5000
06 128 cygwin_select: sel.always_ready 1
07 128 select_stuff::cleanup: calling cleanup routines
08 128 peek_serial: fh->overlapped_armed 0
09 128 set_bits: me 0xA050188, testing fd 3 (/dev/com2)
10 128 set_bits: ready 1
11 128 set_bits: me 0xA081C40, testing fd 1 (/dev/console)
12 128 set_bits: ready 1
13 128 set_bits: me 0xA081C10, testing fd 0 (/dev/console)
14 128 set_bits: ready 1
15 128 select_stuff::poll: returning 3
16 128 select_stuff::cleanup: calling cleanup routines
17 128 select_stuff::~select_stuff: deleting select records
<snip>
18 128 readv: readv (0, 0x22EEB0, 1) nonblocking, sigcatchers 2
19 128 fhandler_base::ready_for_read: read_ready 0, avail 0
20 128 readv: -1 = readv (0, 0x22EEB0, 1), errno 11

select_stuff:poll() calls peek_console in select.cc and this is returning
'true'. This implies that PeekConsoleInput() from Windows indicated there was a
keypress and it sets 'read_ready=true'.  This is seen from lines 01 to 15 of the
log above.

However, the interesting part is in the 'readv' stuff of 'syscalls.cc'. Line 18
comes from syscalls.cc, readv(). bg_check() returns bg_ok.
fhandler_base::ready_for_read() is called.

Why does fhandler_base::ready_for_read() have "read_ready 0", when it should
have been set by PeekConsoleInput() by peek_console() called by select.cc? This
appears to a failure.

But on the other hand, if this function is called again, PeekConsoleInput()
should still return that there is a character on the input and set 'read_ready'
a second time. This is because I don't think ReadConsoleInput() should have 
been called as of yet.

So I don't know where to go from here. Any ideas for going further in analysing
the code?



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