bug-readline
[Top][All Lists]
Advanced

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

Re: [Bug-readline] Refresh readline notion of terminal size


From: Chet Ramey
Subject: Re: [Bug-readline] Refresh readline notion of terminal size
Date: Sun, 17 Jul 2016 14:48:18 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

On 7/14/16 3:22 PM, address@hidden wrote:

> I actually still don't understand Chet's position regarding signal
> handling, FWIW.

I know.  Let's see if I can illustrate it using a model that I touched
on a little in my message to the python folks back in March.

Consider an application that uses multiple threads and multiple processes,
and uses an event-driven model to switch between them.  In this model,
the application tests various input and output sources and multiplexes
between them, and uses signals to perform various control and user
interface functions while that's happening.  Instead of sitting in a
single select() loop waiting for input on readline's input file descriptor,
it uses a select loop to wait for events from multiple sources.  Since
there are more things happening than just sitting and blocking on input,
and more events to be handled than just a character on the standard input
that needs to be collected, readline should not keep its signal handlers
installed.  The application needs to be able to handle signals while it's
doing other things.

The readline callback interface needs to be flexible enough to accommodate
applications that use select to multiplex between multiple threads and
input sources and those that just use select to block waiting for input
on the terminal file descriptor.  Readline can't presume to steal signals
that the application might use for other purposes while it's not active
in rl_callback_read_char().

Frankly, there's no real compelling reason for an application that just
sits in a select loop and calls rl_callback_read_char() to do things that
way.  There's no real difference between that and calling readline().  I
will look for a way for applications to signal to readline that they are
going to use the callback interface like this and cause readline's signal
handlers to persist throughout a series of calls that collects a complete
line.  This will make the signal handling similar to a call to readline().

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/



reply via email to

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