From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6576 invoked by alias); 22 Apr 2011 03:07:33 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 15984 Received: (qmail 13493 invoked from network); 22 Apr 2011 03:07:21 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <110421200715.ZM12476@torch.brasslantern.com> Date: Thu, 21 Apr 2011 20:07:15 -0700 In-reply-to: <20110421180801.GD6357@layslair.ath.cx> Comments: In reply to Anthony Charles "Re: Signal handling/zcurses" (Apr 21, 8:08pm) References: <20110420101911.GA6357@layslair.ath.cx> <110420074048.ZM16389@torch.brasslantern.com> <20110420192234.GB6357@layslair.ath.cx> <110421014823.ZM17325@torch.brasslantern.com> <20110421143145.GC6357@layslair.ath.cx> <110421084717.ZM11635@torch.brasslantern.com> <20110421180801.GD6357@layslair.ath.cx> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-users@zsh.org Subject: Re: Signal handling/zcurses MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Apr 21, 8:08pm, Anthony Charles wrote: } } Unforunately, I see no changes with this patch but with little debug, } I found out that errno is first set to 4 (EINTR), then wgetch is } restarted but failed That would seem to indicate that once the read system call has been interrupted inside wgetch(), it's not possible to pick up where you left off by simply calling wgetch() again. Interestingly, I'm able to reproduce your result with the script you sent -- in spite of the fact that (a) Linux normally has restartable system calls (b) the doc says that "Under the ncurses implementation, handled signals never interrupt getch" and (c) my zsh is linked with -lncursesw so this really should work. An strace says read(0, 0xbff8d41f, 1) = ? ERESTARTSYS (To be restarted) --- SIGUSR1 (User defined signal 1) @ 0 (0) --- rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [USR1 CHLD], 8) = 0 rt_sigprocmask(SIG_SETMASK, [USR1 CHLD], ~[KILL STOP RTMIN RT_1], 8) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [USR1 CHLD], 8) = 0 write(1, "USR1\n", 5) = 5 rt_sigprocmask(SIG_BLOCK, [CHLD], [USR1 CHLD], 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [CHLD], [USR1 CHLD], 8) = 0 sigreturn() = ? (mask now [CHLD]) rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0 This is strange because at this point [after sigreturn()] the read() call should have been resumed, but that never happens. GDB confirms that the loop in my patch does call wget_wch() again, so EINTR was returned (which surprises me, see above) but that wget_wch() returns without making any system calls (which I think means it believes the window to be invalid, but I'm not really sure). Everything works (and straces) as expected with STOP/CONT signals. read(0, 0xbfe8360f, 1) = ? ERESTARTSYS (To be restarted) --- SIGSTOP (Stopped (signal)) @ 0 (0) --- --- SIGSTOP (Stopped (signal)) @ 0 (0) --- read(0, 0xbfe8360f, 1) = ? ERESTARTSYS (To be restarted) --- SIGCONT (Continued) @ 0 (0) --- read(0, } Strangely, if I comment my trap and kill -USR1 the script, it } terminates immediately, no debug from curses.c as if it didn't receive } the signal. That's not strange at all -- the default response to USR1 is for the OS to kill the process. If you haven't trapped it, then zsh has not changed that default, so ...