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/
