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

[Phil Muldoon <pmuldoon@redhat.com>]

On 10/10/2018 15:07, Tom Tromey wrote:
>>>>>> "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.

Aha, well I learned something new today!

 
> 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.
 

Ok. I looked at the patch and, from my point of view, it looks fine to
me.  I'll leave any testing decisions in your hands.

Cheers

Phil