Is SIGWINCH fixed to re-enable it's pre-4.3 behavior? If not, why not?

[L. A. Walsh]

From the below, it sounds like you've fixed the problem disallowing
signal handlers to process signals.  SIGWINCH is specifically listed
to use wait methods that allow it to be processed outside of 'read' --
which apparently caused problems such that signal handling was disabled
in reads and not processed in real-time anymore, but when returning from
the read (when the user pressed a key).  This caused breakage in scripts
that relied on this behavior (wanting to process ALARMs, reap-children,
process window-size changes, etc...).

It sounds like, from the release notes, that allowing real-time processing
of signal handlers in read should no longer be an issue if pselect
is used to before read to allow waiting for and processing of real-time
events before reading a character.   So has the regression introduced in
4.3 been fixed?  If not, could it be in a patch?

Thanks,
Linda


Chet Ramey wrote:

> +========== CHANGES ==========
>
> d.  Readline's input handler now performs signal processing if read(2) is
>     interrupted by SIGALRM or SIGVTALRM.
>   
---
  It sounds like the ability for signal handlers to be called while
waiting for input has been restored. 

> h.  Use pselect(2), if available, to wait for input before calling read(2), so
>     a SIGWINCH can interrupt it, since it doesn't interrupt read(2).
>   
----
  Is it the case that pselect is used to allow SIGALRM and SIGVTALRM
to be called while waiting for input?

  Does this mean SIGWINCH also causes signal processing, allowing
signal handlers to called again?  It seems if it is possible to call
other signal handlers while doing a read, then SIGWINCH's sig-handler
should also be callable, is that now the case?