Mail Archives: cygwin/2004/11/23/05:14:53
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/
- Raw text -