Home Original page

Oddity question

Joshua Muskovitz joshm at taconic.net
Tue Feb 26 18:52:23 EST 2002 
FAILS>         self.buf=self.buf+self.my_socket.recv (8)

OK>         aux=self.my_socket.recv (8)
OK>         self.buf=self.buf+aux

This is just a guess, but here goes.  The call to recv() takes some amount
of time.  Perhaps Python is evaluating the "self.buf+" part *before* calling
recv().  It caches the old buffer contents.  Meanwhile, your other thread
prints and clears the value of self.buf.  When recv() returns, it appends
its results to the *already evaluated* self.buf and resets it.  When you use
aux, the caching of self.buf doesn't happen.

you could test this by trying something like this:

cache = self.buf
aux = self.my_socket.recv(8)
self.buf = cache + aux

This should also fail.

But the larger issue here is that what you are experiencing is a "race
condition".  Two threads are each trying to modify the same object
(self.buf), and they are interfering with each other.  A better way to deal
with this is to write separate functions (perhaps named "AppendBuffer" and
"ClearBuffer"?) which use a common mutex.  A mutex is a magic lock where
only one thread can own it at a time.  This makes it impossible for one
thread to muck around with the buffer while the other thread is modifying
it.

--
# Joshua Muskovitz
# joshm at taconic.net
def lyyrs(sig): return '-'.join(sig.split()+["ly y'rs"])
lyyrs('Race conditions suck to debug')




-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----
More information about the Python-list mailing list