[Patches] [ python-Patches-729988 ] Fix for test_logging hanging

SourceForge.net noreply@sourceforge.net
Tue, 29 Apr 2003 22:24:00 -0700


Patches item #729988, was opened at 2003-04-29 20:40
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=729988&group_id=5470

Category: Tests
Group: Python 2.3
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Brett Cannon (bcannon)
>Assigned to: Brett Cannon (bcannon)
Summary: Fix for test_logging hanging

Initial Comment:
test_logging was reportedly hanging on Solaris 8, 9, and at least on 
my OS X box.  The reported hang occured after test 3 finished.

It turns out that the module was using a Condition lock to have the 
TCP server notify the main thread that it had exited by executing a 
'notify' on the lock.  It appears, though, that the server was executing 
its 'notify' before the main thread even reached its 'wait' call on the 
lock and thus hung indefinitely.

Instead of instituting a timeout on the lock, I switched the lock over to 
an Event lock.  It is initially false which I am using to signal the server 
is still running.  The server then does a 'clear' on the lock to set it to 
true.  The main thread, meanwhile, blocks on a 'wait' call on the lock 
which only returns when the lock goes to true; when the TCP server 
makes its 'clear' call.

Obviously the test passes for me with no hanging.

I just need someone to double-check this since I don't have much 
threading experience; I will do the checkin myself.

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2003-04-29 22:23

Message:
Logged In: YES 
user_id=357491

I was reading into the mentioning of the state of the internal flag too much 
from the docs (I do that a lot; joys of having quirky common sense I guess).  
I will change the line and apply the patch.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-04-29 21:04

Message:
Logged In: YES 
user_id=31435

Great sleuthing, Brett!  Makes sense.

You're only off in the lingo:  Events aren't locks, and they're 
neither true nor false.  An Event has either happened (in 
which case it's "set"), or hasn't happened yet (in which 
case it's "clear", which is an Event's initial state).

So the code is fine, but the comment reads strangely.  
Instead of

# Set event lock to True when server is done.

make it

# The server sets socketDataProcessed when it's done.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=729988&group_id=5470