[Top][All Lists]

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

Re: winch trap delayed until keypress

From: Linda Walsh
Subject: Re: winch trap delayed until keypress
Date: Fri, 23 May 2014 11:14:36 -0700
User-agent: Thunderbird

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

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

reply via email to

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