Re: Another sigwaitinfo problem (with testcase)

2012-08-17 Thread Achim Gratz 
Daniel Colascione writes:
 More odd behavior under the 2012-08-16 snapshot:

 1) Start vim
 2) Hit C-z
 3) Run fg
 4) Observe that vim doesn't reappear. Rather, nothing happens, until...
 5) C-c
 6) vim now redisplays and accepts input

I can confirm this behaviour.


Regards,
Achim.
-- 
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds


--
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: Another sigwaitinfo problem (with testcase)

2012-08-16 Thread Christopher Faylor 
On Tue, Aug 14, 2012 at 10:36:39PM -0700, Daniel Colascione wrote:
When run on a Linux machine, this program starts up and blocks on sigwaitinfo.
You can suspend and resume the program using usual job control facilities, and
on SIGINT, the program prints a message and exits. When the program resumes
after being stopped, it prints resumed.

With the 2012-08-07 Cygwin snapshot, this program prints resumed immediately
after receiving SIGTSTP, then fails to respond to any signal, even signals not
in the blocked set. A simpler test program that just calls raise (SIGSTOP)
property stops itself before resuming execution.

This should be fixed in the latest snapshot.

Thanks for the test case.

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: Another sigwaitinfo problem (with testcase)

2012-08-16 Thread Daniel Colascione 
On 8/16/2012 11:43 AM, Christopher Faylor wrote:
 On Tue, Aug 14, 2012 at 10:36:39PM -0700, Daniel Colascione wrote:
 When run on a Linux machine, this program starts up and blocks on 
 sigwaitinfo.
 You can suspend and resume the program using usual job control facilities, 
 and
 on SIGINT, the program prints a message and exits. When the program resumes
 after being stopped, it prints resumed.

 With the 2012-08-07 Cygwin snapshot, this program prints resumed 
 immediately
 after receiving SIGTSTP, then fails to respond to any signal, even signals 
 not
 in the blocked set. A simpler test program that just calls raise (SIGSTOP)
 property stops itself before resuming execution.
 
 This should be fixed in the latest snapshot.
 
 Thanks for the test case.

Thanks for the fix. It's incomplete, though. Previously, C-z would make the
program print resumed, then become insensitive the signals present in
waitmask. With the 2012-08-16 snapshot, C-z stops the program, but on
resumption, it doesn't print resumed. Instead, on resumption, the program
enters the same signal-insensitive state it did with the 2012-08-07 snapshot.



signature.asc
Description: OpenPGP digital signature

Re: Another sigwaitinfo problem (with testcase)

2012-08-16 Thread Daniel Colascione 
On 8/16/2012 8:51 PM, Daniel Colascione wrote:
 On 8/16/2012 11:43 AM, Christopher Faylor wrote:
 On Tue, Aug 14, 2012 at 10:36:39PM -0700, Daniel Colascione wrote:
 When run on a Linux machine, this program starts up and blocks on 
 sigwaitinfo.
 You can suspend and resume the program using usual job control facilities, 
 and
 on SIGINT, the program prints a message and exits. When the program resumes
 after being stopped, it prints resumed.

 With the 2012-08-07 Cygwin snapshot, this program prints resumed 
 immediately
 after receiving SIGTSTP, then fails to respond to any signal, even signals 
 not
 in the blocked set. A simpler test program that just calls raise (SIGSTOP)
 property stops itself before resuming execution.

 This should be fixed in the latest snapshot.

 Thanks for the test case.
 
 Thanks for the fix. It's incomplete, though. Previously, C-z would make the
 program print resumed, then become insensitive the signals present in
 waitmask. With the 2012-08-16 snapshot, C-z stops the program, but on
 resumption, it doesn't print resumed. Instead, on resumption, the program
 enters the same signal-insensitive state it did with the 2012-08-07 snapshot.
 

More odd behavior under the 2012-08-16 snapshot:

1) Start vim
2) Hit C-z
3) Run fg
4) Observe that vim doesn't reappear. Rather, nothing happens, until...
5) C-c
6) vim now redisplays and accepts input




signature.asc
Description: OpenPGP digital signature

Another sigwaitinfo problem (with testcase)

2012-08-14 Thread Daniel Colascione 
When run on a Linux machine, this program starts up and blocks on sigwaitinfo.
You can suspend and resume the program using usual job control facilities, and
on SIGINT, the program prints a message and exits. When the program resumes
after being stopped, it prints resumed.

With the 2012-08-07 Cygwin snapshot, this program prints resumed immediately
after receiving SIGTSTP, then fails to respond to any signal, even signals not
in the blocked set. A simpler test program that just calls raise (SIGSTOP)
property stops itself before resuming execution.

#define _GNU_SOURCE 1
#include unistd.h
#include stdio.h
#include stdlib.h
#include signal.h
#include pthread.h

int
main()
{
sigset_t waitmask;
int sig;

sigemptyset (waitmask);
sigaddset (waitmask, SIGTSTP);
sigaddset (waitmask, SIGINT);
sigprocmask (SIG_BLOCK, waitmask, NULL);

for (;;) {
sig = sigwaitinfo (waitmask, NULL);
fprintf (stderr, got %s\n, sys_siglist[sig]);
if (sig == SIGTSTP) {
raise (SIGSTOP); /* Block until somebody resumes us. */
} else if (sig == SIGINT) {
fprintf(stderr, exiting);
break;
}
}

return 0;
}



signature.asc
Description: OpenPGP digital signature