[Python-Dev] Threading idea -- exposing a global thread lock (original) (raw)

Donovan Baarda abo at minkirri.apana.org.au
Tue Mar 14 17:05:04 CET 2006

On Tue, 2006-03-14 at 00:36 -0500, Raymond Hettinger wrote:

[Guido] > Oh, no!

Before shooting this one down, consider a simpler incarnation not involving the GIL. The idea is to allow an active thread to temporarily suspend switching for a few steps: [...] I disagree that the need is rare. My own use case is that I sometimes add some debugging print statements that need to execute atomically -- it is a PITA because PRINTITEM and PRINTNEWLINE are two different opcodes and are not guaranteed to pair atomically. The current RightWay(tm) is for me to create a separate daemon thread for printing and to send lines to it via the queue module (even that is tricky because you don't want the main thread to exit before a print queued item is completed). I suggest that that is too complex for a simple debugging print statement. It would be great to simply write:

You don't need to use queue... that has the potentially nasty side affect of allowing threads to run ahead before their debugging has been output. A better way is to have all your debugging go through a print_debug() method that acquires and releases a debug_lock threading.Lock. This is simpler as it avoids the separate thread, and ensures that threads "pause" until their debugging output is done.

-- Donovan Baarda <abo at minkirri.apana.org.au> http://minkirri.apana.org.au/~abo/

More information about the Python-Dev mailing list