Re: [RFC] Release the GIL while running a gdb command or expression

[Tom Tromey <tom@tromey.com>]

>>>>> "Phil" == Phil Muldoon <pmuldoon@redhat.com> writes:

>> I don't think this is necessary, mostly because I can't think of when it
>> would be desirable not to release the GIL; but also because when writing
>> Python one doesn't normally have to worry about the GIL -- it's not
>> really a Python-visible feature, nor should it be, since implementations
>> like PyPY don't have it.

Phil> It's not so much an implementation detail that should be exposed to
Phil> the user but rather a change in behavior around gdb.execute. Given
Phil> that now, with this patch, we always release the Python GIL during the
Phil> execution of a GDB command via gdb.execute, any other Python thread
Phil> that was previously blocked by the GIL is now unblocked, and it may
Phil> appear to those threads that the Python thread that initiated the
Phil> gdb.execute has returned from that command when it may not have (this
Phil> is especially so in cases where a GDB command takes seconds to
Phil> complete a command). Also, any other Python threads that wish to
Phil> interact with GDB will have to wait until the GDB event loop returns
Phil> to a state where it is accepting input (at least I think this is
Phil> true).

Actually we forbid using gdb APIs from threads other than the gdb
thread.  From python.texi:

    @value{GDBN} is not thread-safe.  If your Python program uses multiple
    threads, you must be careful to only call @value{GDBN}-specific
    functions in the @value{GDBN} thread.  @code{post_event} ensures
    this.

Phil> This may break some scripts out there. Are these scripts
Phil> relying on what we now classify as a bug or is there is a reasonable
Phil> expectation, on the users' behalf, that a script could rely on GDB's
Phil> previous GIL blocking behavior?  I'm not advocating we should have a
Phil> release_gil parameter, I'm just unsure of the expectations of users
Phil> and scripts out there, and that if we don't provide a mechanism to
Phil> optionally block the GIL, it will cause disruption to any established
Phil> scripts out there.

Phil> I suppose the solution is to either provide a GIL blocking parameter
Phil> or to thoroughly document this new behavior in the manual. What do
Phil> you think?

I think there's little risk of this breaking anything.  It seems like
just an ordinary bug fix to me.

Tom