From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | chris(at)bitmead(dot)com, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] psql and Control-C |
Date: | 2000-02-19 14:12:36 |
Message-ID: | Pine.LNX.4.21.0002191424230.474-100000@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2000-02-18, Tom Lane mentioned:
> > Readline has an official way to preempt is, namely setting rl_done to
> > non-zero. I can take a look how it copes with a longjmp from a signal
> > handler, but I wouldn't set my hopes too high.
>
> Oh? Maybe we don't *need* a longjmp: maybe the signal handler just
> needs to do either send-a-cancel or set-rl_done depending on the
> current state of a flag that's set by the main line code.
I tried that but it doesn't work. On further thought I believe that the
purpose of rl_done is for readline extensions, so that, for example, a
semicolon handler can scan the current line and then immediately return as
if you had pressed enter. When idle, readline hangs on read(), so setting
some variable isn't going to interrupt that.
The longjmp seems to work but I need to test it more. I'm concerned how it
will work across platforms, esp. Windows (being a POSIX thing). Should
there be a configure test or can I assume it on every non-WIN32 system?
--
Peter Eisentraut Sernanders väg 10:115
peter_e(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2000-02-19 14:12:44 | Re: [HACKERS] Date/time types: big changeu |
Previous Message | Peter Eisentraut | 2000-02-19 14:12:24 | Re: SQL compliance |