Re: winch trap delayed until keypress

[Linda Walsh]

Chet Ramey wrote:
> I think you misunderstand.  Applications, in this context, are those
> programs that link with readline ...
----

   Ah... of course, wasn't thinking of apps in that sense.  Was trying
to figure out interactions between programs launched by bash and
signal handling in bash.  Completely different.


> > Wait.. there is a pending bug w/readline and timeouts....
>
> It has to do with the read builtin not setting the right hook for
> readline and readline not doing what it needs to with SIGALRM.  It's
> not anything related to the framework or approach, and unconnected
> to any SIGWINCH issues except that they are both signals.
----

   Indeed... my questions were not coming from the "readline as
library" perspective -- primarily "apps" written in "bash", and
secondarily "apps" run (launched) by bash.

   Given that, regarding the bug in readline & timeouts.  I kept
having problems with the timeouts getting 'lost' if I got interrupted
by a signal like WINCH.  After I'd set a flag in the int-handler
(which was all I did), the read didn't restart correctly such that the
timeout was still in effect.  I.e. it would require a keypress to
force return from readkey.

   I did think about using SIGALRM instead of a timed read, but
I thought there was a good chance that the timed-red used SIGALRM,
itself, and my using it would, at best, be "unproductive".  I wasn't
excited (one might say "not enthusiastic"),  about using a separate
process for input from the console, but I eventually got over it when
I realized that was the best solution for most GUI's having
non-responsiveness issues -- putting user I/O handling in it's own
process so it never is blocked by work or events in the main app.

   Too often in GUI's people put the handling of user-IO and the
implementation of effects/features caused by that I/O in the same
global event loop, so user I/O gets unresponsive when the program is
off in some cpu-bound call or some other I/O-op that is taking longer
than desired (or expected).

   Since that applied to my program (waiting for a timed read wasn't
timing out as it should have), I decided that my general belief about
GUI's needing more threads of execution (in regards to UI (user-
interface) handling), could be just as valid a need in a complex CLUI
as in a GUI.  Generally the more things the main event loops need to
handle, the more likely it is those events will interfere w/basic UI
functionality.

I could elaborate more, but don't want to any _more_ people to sleep.
;-)