Lisp mentality vs. Python mentality

[Paul Rubin]

Carl Banks <pavlovevidence at gmail.com> 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.