On Oct 17, 2014, at 6:11 AM, Phil Muldoon <[email protected]> wrote:
> ...
> Right. gdb.execute won't return until the command has completed.
> Also the Python GIL has been acquired (as this is coming from the
> Python interpreter) and so now Python is also blocked too. So in
> effect the only thing running at this point is the gdb.execute command
> that was invoked (in your case, the continue command). That will
> return, and then the Python GIL will be released and the rest of the
> script will continue.
>
> I have a patch I need to upstream that adds a release_gil keyword to
> gdb.execute. This optionally releases the GIL before executing the
> command. But I have not got around to that yet.
Could you explain why gdb.execute should ever hold onto the GIL while performing the command? I view gdb.execute as akin to an I/O operation, which releases the GIL around the I/O. Another way to look at it is that execute is performing a GDB command. Either that isn’t a Python operation — in which case the GIL is not needed since the data it protects won’t be touched. Or it is a command that (possibly indirectly) invokes another Python operation — in which case the GIL has to be released or you end up with a deadlock.
What am I missing?
paul
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.