From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Nick Roberts <nickrob@snap.net.nz>
Cc: bug-readline@gnu.org, gdb-patches@sourceware.org,
Daniel Jacobowitz <drow@false.org>
Subject: Re: [patch] Fix testsuite annotate-quit race (PR 544)
Date: Wed, 19 Mar 2008 10:13:00 -0000 [thread overview]
Message-ID: <20080319101231.GA5405@host0.dyn.jankratochvil.net> (raw)
In-Reply-To: <18400.58139.937426.478457@kahikatea.snap.net.nz>
On Wed, 19 Mar 2008 10:55:39 +0100, Nick Roberts wrote:
> I am just worried it will break something for Emacs just as a previous change
> that you and Daniel made to readline did.
http://sourceware.org/ml/gdb-patches/2006-11/threads.html#00234
http://sourceware.org/ml/gdb-patches/2006-12/threads.html#00009
> It appear to me that the only problem this FAIL is causing is with the actual
> running of the testsuite. I would be quite happy if this test was just
> removed. Would that work for everyone else?
The problem is unrelated to the annotations and there should be a testcase just
with the "(gdb) " prompt after the annotations support gets obsoleted/removed.
Currently the test described at
http://sourceware.org/ml/gdb-patches/2008-03/msg00270.html
has different output depending on whether you type CTRL-C early enough (during
the "(gdb) " printing) or just later (in poll(2) waiting for input).
With the readline patch proposed there the output is always the same.
I find it a bug as without the artifical `sleep (1)' delay it is very racy.
> but I am just worried it will break something for Emacs just as a previous
> change that you and Daniel made to readline did.
My original patch requiring a readline change AFAIK did not break anything,
unfortunately it did not get accepted for readline. Daniel created an IMO
complicated patch to workaround the readline problem without forking readline
but unfortunately it brought that regression. I find the regression was in
fact only a consequence of the readline interface deficiency.
Regards,
Jan
next prev parent reply other threads:[~2008-03-19 10:13 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-18 22:55 Jan Kratochvil
2008-03-18 23:18 ` Daniel Jacobowitz
2008-03-19 8:11 ` Jan Kratochvil
2008-03-19 8:46 ` Nick Roberts
2008-03-19 9:31 ` Jan Kratochvil
2008-03-19 9:56 ` Nick Roberts
2008-03-19 10:13 ` Jan Kratochvil [this message]
2008-03-21 20:45 ` Jan Kratochvil
2008-03-21 21:04 ` Daniel Jacobowitz
2008-03-21 21:45 ` Daniel Jacobowitz
2008-03-23 11:01 ` Nick Roberts
2008-03-23 16:30 ` Daniel Jacobowitz
2008-03-23 16:44 ` Jan Kratochvil
2008-03-23 17:30 ` Daniel Jacobowitz
2008-03-24 0:07 ` Nick Roberts
2008-03-24 2:58 ` Daniel Jacobowitz
2008-03-24 7:42 ` Jan Kratochvil
2008-03-24 12:00 ` Daniel Jacobowitz
2008-03-24 13:03 ` Jan Kratochvil
2008-03-24 13:27 ` Daniel Jacobowitz
2008-03-25 1:02 ` Chet Ramey
2008-03-25 2:53 ` Daniel Jacobowitz
2008-03-25 15:56 ` Chet Ramey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080319101231.GA5405@host0.dyn.jankratochvil.net \
--to=jan.kratochvil@redhat.com \
--cc=bug-readline@gnu.org \
--cc=drow@false.org \
--cc=gdb-patches@sourceware.org \
--cc=nickrob@snap.net.nz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox