[Python-Dev] Threading idea -- exposing a global thread lock
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 PRINT_ITEM and PRINT_NEWLINE 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