Lisp mentality vs. Python mentality

Paul Rubin http
Mon Apr 27 17:43:09 CEST 2009

Carl Banks <pavlovevidence at> writes:
> > > Presumably you have to protect objects to share them?  There you go:
> > > anytime you try to acquire a lock have the thread check to see whether
> > > to abort.
> >
> > Normally, acquiring a lock doesn't require running code in other
> > threads, at least in the uncontended case.  If you have to switch
> > threads twice in order to acquire a lock, your implementation could
> > use some improvement.
> Come on, you're just making stuff up.  How the *hell* do you get
> switching threads twice out of that?  

I think I mis-read your suggestion.  I thought you meant to query
another thread before acquiring a lock.

Anyway, the usual reason to want to kill a thread is that it's become
unresponsive for some reason, while holding onto some resource like a
lock or a bound socket.  This would be in the category of fault
recovery from conditions that weren't expected ahead of time.

Another situation is when you want to just stop the program
altogether, similar to kill -9'ing it, with no attempt to shut down
gracefully.  Kind of a global ctrl-C.  Right now there is no way to do
that for a multithreaded program except by literally sending a process
kill, which is pretty ugly.

More information about the Python-list mailing list