[Python-Dev] POSIX thread code

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 <wink>.

> 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.