[Python-Dev] POSIX thread code (original) (raw)

Tim Peters tim.one@comcast.net
Mon, 18 Mar 2002 20:05:33 -0500

[Guido]

I was thinking of the situation where a user learning about threads and locks gets in trouble in an interactive session, by typing something that grabs a lock that won't ever be released. Telling them they shouldn't have done that isn't going to help them.

It will if it teaches them not to do it again .

IMO this is the same kind of situation as comparing a recursive list to itself: this used to crash due to a stack overflow, and we cared enough about this "don't do that then" situation to fix it.

A prime difference is that I've never seen anyone report this problem, and I still pay attention to the Help and Tutor lists. Reports of recursive compare blowups came around several times each year.

... Yeah, unfortunately the only implementation technique I have to offer right now is to turn all acquire calls internally into a loop around an acquire call with a timeout in the order of 1 second, and to check signals each time around the loop. :-(

I think a practical solution would need a different lock implementation at the lowest level. The new POSIX semaphore-based lock implementation is more-or-less friendly to this, although it looks painful even so. I'm not sure what could be done on Windows, but am not inclined to take it seriously before Orlijn reports the bug.