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

[Tom Tromey <tom at tromey dot com>]

>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:

Tom> If you ignore this then I have a version that works.  Racy in theory but
Tom> maybe not in practice.

Pedro> We have plenty of tests that shouldn't be racy in theory but are
Pedro> in practice.  So I'd instead assume that in practice someone will
Pedro> definitely run into the race.

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

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

It took me a little experimenting to understand why this can't work.

The main thread can't run any Python code at all.  If it does run Python
code, then Python might release the GIL.  And, when dealing with thread
primitives like mutexes or whatnot, it certainly will.  However, if the
main thread does release the GIL, then that invalidates the test --
since we are trying to test that the GIL is released under ordinary
circumstances.

I'm back to not seeing a way to test this.

Tom