[Spread-users] Spread python module
Guido van Rossum
guido at python.org
Thu Apr 25 10:58:50 EDT 2002
> I agree with this statement of the problem and we will be adding the
> new disconnect semantics soon.
> I just want to make two comments about the threaded client
> Is the Python module is linking with libsp or libtsp (the regular or
> threadsafe Spread C-library) I'm guessing it is the regular libsp
> since you do your own locking.
No, we link with libtsp; Python has a global lock that serializes
Python bytecode execution, but you need to release that when you do a
blocking I/O call so other Python threads can make progress. (Python
threads are OS threads.) It turns out that the lock we added to fix
the disconnect race condition completely serialized calls into Spread,
but this was not our intention!
> I can understand just removing the lock which causes the deadlock,
> but because the lock removal can cause 'unexplainable' behavior with
> connections being reused inappropriately, it seems like a documeted
> deadlock is safer (since there is a workaround for the deadlock by
> using select) Then when the spread library is fixed, a new release
> of the Python module could relax the lock to regain the lost
> concurrency and negate teh deadlock possibility. It is certainly
> your call that just seemed safer to me.
The disconnect race condition is pretty hard to provoke; I believe
it's more a theoretical blemish than a practical issue. So I'd rather
remove the lock to get back the multithreaded behavior we had in
version 1.0 of the Python module.
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Spread-users