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

Guido van Rossum guido@python.org
Mon, 18 Mar 2002 09:23:39 -0500

> It's one of the few places where code can be blocked in a > system call (if you want to call a lock wait a system call -- it's > close enough for me)

I'd be more upset about that if it weren't the purpose of lock.acquire() to block . If a user doesn't want to block, they should poll, acquire-with-timeout, or fix their bad assumptions.

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.

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.

> and a ^C doesn't stop it, and that can be annoying at times. > > Of course, if it's not the main thread, signals including SIGINT > shouldn't do anything, but that's a separate issue.

Why should the main thread act differently?

By fiat, only the main thread in Python is supposed to get signals.

> Breaking the main thread IMO is useful behavior for interactive > programs and for scripts invoked from the command line.

Being able to interrupt any thread may be useful. I guess I don't see what's especially useful about breaking the main thread. If my program is hosed, I'd just as soon kill the whole thing.

Interactively, the main thread is important.

> (In practice, this is probably only interesting for interactive > use -- if you hang your main thread on a deadlock, there's no way > to get your prompt back, and that may mean no way to figure out > what went wrong or save stuff you wanted to save.

Hmm. The "save stuff" use may be most valuable for non-interactive long-running jobs, assuming that it's possible to save stuff despite that the rest of your threads remain deadlocked (implying they're all holding some lock). I suppose if you can guess which lock the main thread broke out of, you could at least release that one and hope for some progress ...

I wasn't thinking of long-running non-interactive jobs. If you design one of those, you should know what you are doing. I was thinking of the poor interactive user who hung their interpreter by accident.

I don't know. If the possibility were there, I expect one could, with care, rely on its details to build some more-or-less useful scheme on top of it -- at least on platforms where it worked. It's really not all that attractive on its own; maybe learning how to build efficient interruptible locks x-platform could lead to a more general gimmick, though.

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

--Guido van Rossum (home page: http://www.python.org/~guido/)