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