On 5/22/14, 4:47 PM, Linda Walsh wrote:
>
>
> Chet Ramey wrote:
>> On 5/22/14, 1:16 AM, Linda Walsh wrote:
>>
>> Further complicating things is the fact that there is not any portable
>> way to specify that SIGWINCH should interrupt system calls. There is
>> the SA_RESTART flag that says *not* to fail with EINTR, but there is no
>> portable flag that has the opposite effect. (You don't want SIGWINCH to
>> interrupt system calls anyway; it's supposed to be transparent.)
>>
>>> But it sounds like my winch handler that would tell me the size of
>>> a resized screen will now be broken.
>>
>> I told you it would need to be changed almost a year ago:
>>
>> http://lists.gnu.org/archive/html/bug-bash/2013-06/msg00119.html
> ----
> How would you suggest changing it so that it continues to work?
I'm not sure it can be without changing readline from how it works in
the current version.
> I.e. if bash traps the signal but doesn't propagate it, it seems
> bash is "sitting on" the needed data.
Not really. Bash gets the signal and defers handling it until it's not in
a signal handler context. You shouldn't do too much in a signal handler;
bash played fast and loose with signal handling in prior versions and can't
do that any more. However, see below about using a readline signal hook.
> Effectively, readline is going off to sleep and not responding to
> external events coming from a windowing system. Even if I have a
> timer-interrupt or wakeup call, that woke up every 1/2 or 1/10th
> second, it wouldn't able to see if WINCH happened because
> readline would have caught the interrupt and set it's flag but won't
> deliver it to a script-signal handler until some keypress:
> is that right?
Not quite. You have to think about the difference between a signal that
interrupts a system call, like SIGALRM, and a signal like SIGWINCH that
does not. If the system call isn't interrupted, readline doesn't have an
opportunity to do anything until it returns. I can look at changing
readline so that a SIGWINCH interrupts system calls, but I will have to
look at the code more before doing it. Having system calls interrupted
in unexpected places leads to hard-to-find problems, and SIGWINCH is
supposed to be transparent. I will play around with it.
(I should clarify my statement from the previous message. SA_RESTART will
force system call restart. Not specifying it will result in system-default
behavior, which in most -- but not all -- cases will interrupt some -- but
not all -- system calls. You'd like to have consistent behavior across
all systems.)
>
> Or would a script even be able to be woken up on a timer interrupt?
> i.e. if you don't deliver signals until a user keypress, how would
> an alarm/timeout handler be called?
>
> If they are called, how are they different from WINCH?
See above. Readline is able to run its signal handler if the read system
call is interrupted, and it will also call an application signal handling
hook for those applications that would like to run code on receipt of a
signal before readline returns. A calling application should structure
things the way bash does: a small function to set a flag on signal receipt
and code to act on that flag and do whatever processing is necessary when
it is `safe'. It's that second function that bash registers as readline's
signal hook.
> It seems like bash would have to do something similar to avoid
> problems.
>
> Perhaps that's the solution that is needed to avoid the race
> problems 4.2 was having?
The bash-4.3 solution is acceptable. I'm not really enthusiastic about
making the shell multi-threaded like that.
> If bash doesn't do it, how can a script get the notification?
Scripts aren't really the problem here. We're mostly talking about the
interaction between readline and the applications that use it. While
you can use readline in a script -- and there is a pending bug with
readline and timeouts in scripts when called by the read builtin -- it's
not the primary use case. And SIGWINCH is the only signal subject to
this problem.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
