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

[Pedro Alves <palves@redhat.com>]

On 10/16/2018 10:45 PM, Tom Tromey wrote:
>>>>>> "Tom" == Tom Tromey <tom@tromey.com> writes:
> 
> Tom> Also the Python code is calling print on a gdb stream in a background
> Tom> thread, which is a no-no.
> 
> If you ignore this then I have a version that works.  Racy in theory but
> maybe not in practice.
We have plenty of tests that shouldn't be racy in theory but are
in practice.  So I'd instead assume that in practice someone will
definitely run into the race.

Do we really need to rely on printing to check this?  If the
the gdb.execute command can run some more python code, then
we could try using a couple python mutexes for proving the
non-main thread runs.  

So the non-main thread would wait on mutex1 which starts owned
by the main thread.  The main thread unlocks mutex1 and blocks
on mutex2, waiting for the non-main thread to release it.
The non-main thread should now run, and is now the mutex1 owner.
It now releases mutex2.  The main thread now unblocks, and the
test succeeds.  If we don't release the GIL properly, then
the non-main thread won't run, and the testcase times out.

Or something along those lines.

Thanks,
Pedro Alves