[Top][All Lists]

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

Re: [Bug-readline] [PATCH] Gnuplot on macOS does not suspend by Control-

From: Chet Ramey
Subject: Re: [Bug-readline] [PATCH] Gnuplot on macOS does not suspend by Control-z
Date: Wed, 22 Nov 2017 21:27:51 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

On 11/22/17 9:14 PM, Rin Okuyama wrote:

> Hmm, in the 1st ifdef block in this function,
> On 2017/11/22 19:07, Rin Okuyama wrote:
>> int getc_wrapper(FILE *fp) {
>>      fd_set fds;
>>      int fd = fileno(fp);
>>      int ierr;
>>      if (external_fd >= 0) {
>>          do {
>>              FD_ZERO(&fds);
>>              FD_SET(fd, &fds);
>>              FD_SET(external_fd, &fds);
>>              extern int _rl_caught_signal;
>>              void _rl_signal_handler(int);
>>              if (_rl_caught_signal)
>>                  _rl_signal_handler(_rl_caught_signal);
>> #endif
>>              ierr = select(external_fd + 1, &fds, 0, 0, NULL);
>>              ...
>>          } while (!FD_ISSET(fd, &fds));
>>      }
>>      int rl_getc(FILE*);
>>      return rl_getc(fp);
>> #else
>>      return getc(fp);
>> #endif
>> }
> _rl_signal_handler() cannot be replaced with rl_getc(fp) neither with
> fp = stdin, stdout, nor stderr. If so, the caller waits input from tty.

Yes, it can.  If you act when select() returns -1/EINTR, check for a
caught signal, and break out of the loop, it should do what you want.
(I'm not sure why you put the signal check before the call to select().)
The reason it will work is that the first thing rl_getc does is to check
for and handle any caught signals, so you can be sure that calling it
when you've detected a signal will cause the signal handler to be invoked.
It's just adding a dependency on a particular implementation.

> Also, I found that the problem is not peculiar to macOS; gnuplot does
> not suspend by Control-z on NetBSD 8-current. Could you implement some
> public function to call _rl_signal_handler() by any chance? It would
> help me a lot.

I'm not sure there's a compelling reason to expose readline's internal
signal handling to applications. If you really need it, there are a
couple of workarounds, both covered here.

``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]