[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: signals interrupting wgetch

From: John Gruenenfelder
Subject: Re: signals interrupting wgetch
Date: Thu, 21 Jul 2005 17:10:55 -0700
User-agent: Mutt/1.5.9i

On Thu, Jul 21, 2005 at 07:33:10PM -0400, Thomas Dickey wrote:
>But the handled signals don't include SIGALRM.  (I see that the manpage
>does not list them).  Checking the code, the apparent intent of that
>comment was to reflect the behavior for these signals:
>       SIGTSTP
>       SIGWINCH

Okay, understood.

>>Until today, this was the case.  Today I updated the kernel from 2.6.11 to
>>2.6.12.  This is on a Debian Sid (current) machine.
>>The signal in question is SIGALRM which is generated every two seconds.
>>When the signal occurs, wgetnstr returns -1.  Checking errno (via perror), 
>>error is:
>> "Interrupted system call"
>I assume your program has a handler for SIGALRM, and that the EINTR is
>just reporting that the read was interrupted.

Yes, I have a SIGALRM handler.  Not mentioned in my original email, however,
is that this program also has two threads.  I know that threading will
complicate signal management, but since I was using only one signal I didn't
think it would matter.  But, as you've pointed out above, I forgot that
ncurses has its own handlers for some signals.

The signal handler is in thread 1, while the call to wgetnstr is in the
other thread (2).  My understanding is that both threads will get the signal.
Previously, thread 1 handled the signal and thread 2 simply ignored it.
Unfortunately, there is no way to tell a single thread to ignore a particular
signal.  Since it's all one process there's just one signal mask.

So... perhaps on reflection, it would be best to drop the signal approach
since it could misbehave in other ways again in the future.

>>By changing part of my code, I could do with out the timer which generates
>>SIGALRM and just poll the clock, but I'd like to know why the behavior 
>>or if perhaps I am doing something wrong.
>Well, as you said - the kernel changed.  Perhaps that was a bug(fix).

I'll grep through the changelog to see if I find anything about signals that
seems pertinent.

>>For reference, the extent of my ncurses configuration is:
>> initscr();
>> cbreak();
>> nonl();
>> keypad(stdscr, TRUE);
>> main_win = newwin(LINES - 1, COLS, 0, 0);
>> scrollok(main_win, TRUE);
>>And then I proceed to start reading/writing main_win.
>I assume it's more complicated than that - I checked by sending SIGALRM
>to a program executing in wgetnstr() just now, and it stopped the program.

Well, I meant that the setup specific to ncurses is limited to that.  The
program has a lot more complexity involving serial I/O, CAN bus I/O, setting
up signals, etc.

As long as the subject is up, are there any caveats I should know about when
using ncurses in a multithreaded program?  I don't recall seeing anything
specific in the documentation.

--John Gruenenfelder    Research Assistant, Steward Observatory, U of Arizona
Try Weasel Reader for PalmOS  --  http://gutenpalm.sf.net
"This is the most fun I've had without being drenched in the blood
of my enemies!"
        --Sam of Sam & Max

reply via email to

[Prev in Thread] Current Thread [Next in Thread]