RetroSearch Browse

Tue Mar 14 17:05:04 CET 2006 · https://mail.python.org/pipermail/python-dev/2006-March/062370.html

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/

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2006-March/062370.html below:

[Python-Dev] Threading idea -- exposing a global thread lock