This is the mail archive of the
mailing list for the Cygwin project.
Madness with the 'select' function, sigalrm, and stdout. (CYGWIN_NT-6.1-WOW64)
- From: Robert F <squaretriangle at hotmail dot co dot uk>
- To: cygwin at cygwin dot com
- Date: Tue, 17 Jan 2012 22:16:19 +0000 (UTC)
- Subject: Madness with the 'select' function, sigalrm, and stdout. (CYGWIN_NT-6.1-WOW64)
This could be a cygwin bug, but I'm not 100% sure. It may even be a weird
interaction with the windows console.
I have a single threaded app that loops, polls network activity with a 'select'
function and interrupts the flow of the loop when a SIGALRM signal is ran, the
handler of which sets a variable that the loop responds to.
While this app more-or-less ran fine in its native linux environment, when
trying to run it at home in cygwin a problem occurs. Basically, between about
2-100 seconds of starting the process (on average), the alarm signal never runs
as scheduled and never runs again, except for one more time when I hit CTRL+C
(which I know by inserting debugging output into the signal handler).
The funny thing is the app happily continues looping and calling the 'select'
function, it just never gets interrupted by an alarm signal. The select function
handles cases of EINTR where it was interrupted by an alarm, btw (sockets are
nonblocking and timeout is 1 second).
Now here's the REALLY weird bit. IF I insert a printf (with newline terminated
string) after the select function, _the problem never occurs_. If there's no
newline, the printed strings are buffered without being shown, until either a
newline arrives or I hit CTRL-C.
Doesn't work if I put it before the select function, only after.
I haven't included any io streams into the fd_sets passed to the select
function, in case you were wondering. They are zeroed and then only receive
This has me stumped.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple