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: select() read() and write() on /dev/console


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/


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