select() not interrupted by signals

select() not interrupted by signals

[Thomas Wolff]

[-- Attachment #1: Type: text/plain, Size: 782 bytes --]

I had previously reported "select() hanging after terminal killed" 
(http://cygwin.com/ml/cygwin/2011-05/msg00418.html).
It turns out that select() does not get interrupted by a SIGWINCH signal 
either (with likely the same cause).
This raises problems with interactive programs that want to react to 
window size changes (like text editors).

See attached updated test case; run the program, while select() is 
waiting (before 5 second timeout each), change window size and see no 
interrupt.
On other systems, select() is interrupted (test case: from mintty, 
remote login to SunOS; also showing the terminal is not involved in the 
problem).

This bug did not exist in cygwin 1.5; I see some Changelog entries from 
2011-12-13 or 2012-01-22 which might be related.
------
Thomas

[-- Attachment #2: select-intr.c --]
[-- Type: text/plain, Size: 1258 bytes --]

#include <stdio.h>
#include <stdlib.h>

#include <sys/select.h>
#include <errno.h>

#include <signal.h>

int
peek (int fd, int msec)
{
	fd_set readfds;
	fd_set exceptfds;
	struct timeval timeoutstru;
	int nfds;

	FD_ZERO (& readfds);
	FD_SET (fd, & readfds);
	FD_ZERO (& exceptfds);
	FD_SET (fd, & exceptfds);
	timeoutstru.tv_sec = msec / 1000;
	timeoutstru.tv_usec = (msec % 1000) * 1000;

	errno = 0;
	printf ("calling select\n");
	nfds = select (fd + 1, & readfds, 0, & exceptfds, & timeoutstru);
	printf ("select -> %d (%s), read %02X except %02X\n", 
		nfds, strerror (errno), readfds, exceptfds);

	return nfds;
}

void
catch_HUP (int hup)
{
	printf ("HUP\n");
	signal (SIGHUP, catch_HUP);
}

void
catch_WINCH (int hup)
{
	printf ("WINCH\n");
	signal (SIGWINCH, catch_WINCH);
}

int
main ()
{
	int fdstdin = 0;

	system ("stty -icanon");
	signal (SIGHUP, catch_HUP);
	signal (SIGWINCH, catch_WINCH);

	while (1) {
		char buf;
		int buflen = 1;

		int nfds = peek (fdstdin, 5000);
		if (nfds > 0) {
			int n;

			printf ("calling read\n");
			errno = 0;
			n = read (fdstdin, & buf, buflen);
			if (n <= 0) {
				printf ("read -> %d (%s); exit\n", n, strerror (errno));
				exit (0);
			}
			printf ("read -> %d: %c\n", n, buf);
		}
		sleep (2);
	}
}



[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

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

Re: select() not interrupted by signals

[Corinna Vinschen]

On Jan 11 09:41, Thomas Wolff wrote:
> I had previously reported "select() hanging after terminal killed"
> (http://cygwin.com/ml/cygwin/2011-05/msg00418.html).
> It turns out that select() does not get interrupted by a SIGWINCH
> signal either (with likely the same cause).
> This raises problems with interactive programs that want to react to
> window size changes (like text editors).
> 
> See attached updated test case; run the program, while select() is
> waiting (before 5 second timeout each), change window size and see
> no interrupt.
> On other systems, select() is interrupted (test case: from mintty,
> remote login to SunOS; also showing the terminal is not involved in
> the problem).
> 
> This bug did not exist in cygwin 1.5; I see some Changelog entries
> from 2011-12-13 or 2012-01-22 which might be related.

Just for clarity, did you test with the latest snapshot?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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

Re: select() not interrupted by signals

[Thomas Wolff]

On 11.01.2013 09:52, Corinna Vinschen wrote:
> On Jan 11 09:41, Thomas Wolff wrote:
>> I had previously reported "select() hanging after terminal killed"
>> (http://cygwin.com/ml/cygwin/2011-05/msg00418.html).
>> It turns out that select() does not get interrupted by a SIGWINCH
>> signal either (with likely the same cause).
>> This raises problems with interactive programs that want to react to
>> window size changes (like text editors).
>>
>> See attached updated test case; run the program, while select() is
>> waiting (before 5 second timeout each), change window size and see
>> no interrupt.
>> On other systems, select() is interrupted (test case: from mintty,
>> remote login to SunOS; also showing the terminal is not involved in
>> the problem).
>>
>> This bug did not exist in cygwin 1.5; I see some Changelog entries
>> from 2011-12-13 or 2012-01-22 which might be related.
> Just for clarity, did you test with the latest snapshot?
No, with the source package of the latest release.
And I can't test with the snapshot as it doesn't compile here (after 
fresh download and unpack):

In file included from 
/usr/src/cygwin-snapshot-20130107-1/newlib/libc/include/sys/types.h:61:0,
                  from ../../.././winsup/cygwin/winsup.h:29,
                  from 
../../.././winsup/cygwin/lib/_cygwin_crt0_common.cc:11:
/usr/src/cygwin-snapshot-20130107-1/newlib/libc/include/sys/_types.h:63:20: 
schwerwiegender Fehler: stddef.h: No such file or directory
Kompilierung beendet.

------
Thomas

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

Re: select() not interrupted by signals

[Corinna Vinschen]

On Jan 11 13:55, Thomas Wolff wrote:
> On 11.01.2013 09:52, Corinna Vinschen wrote:
> >On Jan 11 09:41, Thomas Wolff wrote:
> >>I had previously reported "select() hanging after terminal killed"
> >>(http://cygwin.com/ml/cygwin/2011-05/msg00418.html).
> >>It turns out that select() does not get interrupted by a SIGWINCH
> >>signal either (with likely the same cause).
> >>This raises problems with interactive programs that want to react to
> >>window size changes (like text editors).
> >>
> >>See attached updated test case; run the program, while select() is
> >>waiting (before 5 second timeout each), change window size and see
> >>no interrupt.
> >>On other systems, select() is interrupted (test case: from mintty,
> >>remote login to SunOS; also showing the terminal is not involved in
> >>the problem).
> >>
> >>This bug did not exist in cygwin 1.5; I see some Changelog entries
> >>from 2011-12-13 or 2012-01-22 which might be related.
> >Just for clarity, did you test with the latest snapshot?
> No, with the source package of the latest release.
> And I can't test with the snapshot as it doesn't compile here (after
> fresh download and unpack):

You could test using the binary...

> In file included from /usr/src/cygwin-snapshot-20130107-1/newlib/libc/include/sys/types.h:61:0,
>                  from ../../.././winsup/cygwin/winsup.h:29,
>                  from
> ../../.././winsup/cygwin/lib/_cygwin_crt0_common.cc:11:
> /usr/src/cygwin-snapshot-20130107-1/newlib/libc/include/sys/_types.h:63:20:
> schwerwiegender Fehler: stddef.h: No such file or directory
> Kompilierung beendet.

stddef.h is provided by the compiler:

$ ls -l /usr/lib/gcc/i686-pc-cygwin/4.5.3/include/stddef.h
-rw-r--r-- 1 corinna vinschen 12542 Oct 23  2011 /usr/lib/gcc/i686-pc-cygwin/4.5.3/include/stddef.h
$ cygcheck -f /usr/lib/gcc/i686-pc-cygwin/4.5.3/include/stddef.h
gcc4-core-4.5.3-3

I don't see how this can fail.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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

Re: select() not interrupted by signals

[Christopher Faylor]

On Fri, Jan 11, 2013 at 09:41:37AM +0100, Thomas Wolff wrote:
>I had previously reported "select() hanging after terminal killed" 
>(http://cygwin.com/ml/cygwin/2011-05/msg00418.html).
>It turns out that select() does not get interrupted by a SIGWINCH signal 
>either (with likely the same cause).
>This raises problems with interactive programs that want to react to 
>window size changes (like text editors).
>
>See attached updated test case; run the program, while select() is 
>waiting (before 5 second timeout each), change window size and see no 
>interrupt.

"No interrupt"?  I see a "HUP" but select() keeps going.  That was the
way I designed it but apparently that differs from the way Linux works.
select() is not restartable like read() or write().

That behavior should be fixed in the next snapshot.  If you are seeing
something different than this then that is not fixed.

cgf

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

Re: select() not interrupted by signals

[Thomas Wolff]

Am 11.01.2013 16:38, schrieb Christopher Faylor:
> On Fri, Jan 11, 2013 at 09:41:37AM +0100, Thomas Wolff wrote:
>> I had previously reported "select() hanging after terminal killed"
>> (http://cygwin.com/ml/cygwin/2011-05/msg00418.html).
>> It turns out that select() does not get interrupted by a SIGWINCH signal
>> either (with likely the same cause).
>> This raises problems with interactive programs that want to react to
>> window size changes (like text editors).
>>
>> See attached updated test case; run the program, while select() is
>> waiting (before 5 second timeout each), change window size and see no
>> interrupt.
> "No interrupt"?  I see a "HUP" but select() keeps going.  That was the
> way I designed it but apparently that differs from the way Linux works.
> select() is not restartable like read() or write().
>
> That behavior should be fixed in the next snapshot.  If you are seeing
> something different than this then that is not fixed.
After Corinna wrote:
> You could test using the binary...
Yes, fixed with latest snapshot, thanks a lot. At least as far as I am 
concerned, i.e.
Not sure what exactly you mean with "select is not restartable" -
actually, that made me test again more deeply, and it seems you 
interrupt select() now on every signal;
as I understood it should only get interrupted on a signal related to a 
file descriptor for which the bit in the exceptfds vector is set...
I'll recheck that on Unix next week.
------
Thomas

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

Re: select() not interrupted by signals

[Christopher Faylor]

On Sat, Jan 12, 2013 at 06:41:27PM +0100, Thomas Wolff wrote:
>Am 11.01.2013 16:38, schrieb Christopher Faylor:
>> On Fri, Jan 11, 2013 at 09:41:37AM +0100, Thomas Wolff wrote:
>>> I had previously reported "select() hanging after terminal killed"
>>> (http://cygwin.com/ml/cygwin/2011-05/msg00418.html).
>>> It turns out that select() does not get interrupted by a SIGWINCH signal
>>> either (with likely the same cause).
>>> This raises problems with interactive programs that want to react to
>>> window size changes (like text editors).
>>>
>>> See attached updated test case; run the program, while select() is
>>> waiting (before 5 second timeout each), change window size and see no
>>> interrupt.
>> "No interrupt"?  I see a "HUP" but select() keeps going.  That was the
>> way I designed it but apparently that differs from the way Linux works.
>> select() is not restartable like read() or write().
>>
>> That behavior should be fixed in the next snapshot.  If you are seeing
>> something different than this then that is not fixed.
>After Corinna wrote:
>> You could test using the binary...
>Yes, fixed with latest snapshot, thanks a lot. At least as far as I am 
>concerned, i.e.
>Not sure what exactly you mean with "select is not restartable" -

http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigaction.html

Look for "restart".

>actually, that made me test again more deeply, and it seems you 
>interrupt select() now on every signal;
>as I understood it should only get interrupted on a signal related to a 
>file descriptor for which the bit in the exceptfds vector is set...
>I'll recheck that on Unix next week.

I have standard test cases for select() which do not use the "exceptfds"
field.  They are interrupted by a signal on both Linux and Cygwin.  I
don't see anything in the Single Unix Specification or Linux man page
which would indicate that signals are in any way related to exceptfds.

Also:

http://stackoverflow.com/questions/1342712/nix-select-and-exceptfds-errorfds-semantics

cgf

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

Re: select() not interrupted by signals

[Thomas Wolff]

Am 12.01.2013 20:14, schrieb Christopher Faylor:
> On Sat, Jan 12, 2013 at 06:41:27PM +0100, Thomas Wolff wrote:
>> Am 11.01.2013 16:38, schrieb Christopher Faylor:
>>> On Fri, Jan 11, 2013 at 09:41:37AM +0100, Thomas Wolff wrote:
>>>> ...
>>> ...
>>> select() is not restartable like read() or write().
>>>
>>> That behavior should be fixed in the next snapshot.  If you are seeing
>>> something different than this then that is not fixed.
>> ...
>> Not sure what exactly you mean with "select is not restartable" -
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigaction.html
>
> Look for "restart".
>
>> actually, that made me test again more deeply, and it seems you
>> interrupt select() now on every signal;
>> as I understood it should only get interrupted on a signal related to a
>> file descriptor for which the bit in the exceptfds vector is set...
>> I'll recheck that on Unix next week.
> I have standard test cases for select() which do not use the "exceptfds"
> field.  They are interrupted by a signal on both Linux and Cygwin.  I
> don't see anything in the Single Unix Specification or Linux man page
> which would indicate that signals are in any way related to exceptfds.
Right, I had obviously misinterpreted the meaning of that vector. Thanks 
for the references.
Current patch is fine, checked with Linux as well.
> Also:
>
> http://stackoverflow.com/questions/1342712/nix-select-and-exceptfds-errorfds-semantics

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