From: Phil Muldoon <pmuldoon@redhat.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: Paul Koning <paulkoning@comcast.net>, gdb-patches@sourceware.org
Subject: Re: Python: fetch value when building gdb.Value object
Date: Mon, 03 Oct 2011 10:22:00 -0000 [thread overview]
Message-ID: <m3ty7qgysz.fsf@redhat.com> (raw)
In-Reply-To: <20111001090443.GA11227@host1.jankratochvil.net> (Jan Kratochvil's message of "Sat, 1 Oct 2011 11:04:43 +0200")
Jan Kratochvil <jan.kratochvil@redhat.com> writes:
> On Wed, 28 Sep 2011 22:40:50 +0200, Paul Koning wrote:
>> If I use RETURN_MASK_ERROR and control/C is hit, does that mean the
>> currently running code aborts and the outer handler that does have
>> RETURN_MASK_ALL is entered?
>
> Yes.
>
>> If so, most of the Python code seems to be a candidate for
>> RETURN_MASK_ERROR.
>
> In fact I do not know, it is a Python thing.
>
> RETURN_MASK_ALL is right if returned PyExc_KeyboardInterrupt will really abort
> any execution of Python code. It is probably so, as suggested by:
> http://docs.python.org/library/exceptions.html#exceptions.KeyboardInterrupt
>
> RETURN_MASK_ERROR is right otherwise, but only if it is safe to longjmp out
> from a code called by Python. This may not be true. Python may be C++
> exceptions throwing safe but it cannot be safe for the GDB longjmp exceptions.
> But this case would mean Python is buggy for CTRL-C on its own so
> RETURN_MASK_ERROR probably is not right.
Jan asked me to look at all the cases. I just have not had time to do
it yet. Too me, the RETURN_MASK in many cases in the Python code is far
too liberal, and should, as Jan notes, be reduced to RETURN_MASK_ERROR.
I am not sure it is just a mechanical change as each scenario has to be
carefully reviewed to understand if in fact an interrupt should be
allowed according to the Python API.
Cheers,
Phil
next prev parent reply other threads:[~2011-10-03 10:22 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-21 16:17 Paul Koning
2011-09-28 19:29 ` Phil Muldoon
2011-09-28 20:06 ` Paul Koning
2011-10-04 15:43 ` Tom Tromey
2011-09-28 20:42 ` Paul Koning
2011-10-01 9:05 ` Jan Kratochvil
2011-10-03 10:22 ` Phil Muldoon [this message]
2011-10-04 15:40 ` Tom Tromey
2011-10-01 9:29 ` Jan Kratochvil
2011-10-01 10:23 ` Pedro Alves
2011-10-01 11:03 ` Jan Kratochvil
2011-10-01 12:17 ` Python: fetch value when building gdb.Value object [rediff] Jan Kratochvil
2011-10-01 18:58 ` Paul Koning
2011-10-03 10:19 ` Phil Muldoon
2011-10-03 16:16 ` Paul Koning
2011-10-01 1:00 ` [PING] [RFA] Re: Python: fetch value when building gdb.Value object Paul Koning
2011-10-04 15:45 ` Tom Tromey
2011-10-04 15:51 ` Paul Koning
2011-10-14 20:03 ` Tom Tromey
2011-10-14 20:30 ` Paul Koning
2011-10-19 20:56 ` Tom Tromey
2011-10-19 20:58 ` Paul Koning
2011-10-20 15:09 ` Tom Tromey
2011-10-21 7:46 ` Paul Koning
2011-10-21 17:13 ` Tom Tromey
2011-10-14 23:36 ` Jim Blandy
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=m3ty7qgysz.fsf@redhat.com \
--to=pmuldoon@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
--cc=paulkoning@comcast.net \
/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