This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] Release the GIL while running a gdb command or expression
>>>>> "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