Thread-killing, round 666 (was Re: Lisp mentality vs. Python mentality)

[John Nagle]

David Bolen wrote:
> Vsevolod <vseloved at gmail.com> writes:
> 
>> On Apr 27, 11:31 pm, David Bolen <db3l.... at gmail.com> wrote:
>>> I'm curious - do you know what happens if threading is implemented as a
>>> native OS thread and it's stuck in an I/O operation that is blocked? How
>>> does the Lisp interpreter/runtime gain control again in order to execute
>>> the specified function?  I guess on many POSIX-ish environments,
>>> internally generating a SIGALRM to interrupt a system operation might
>>> work, but it would likely have portability problems.
>> We're arguing to the old argument, who knows better, what the programmer
>> wants: language implementor or the programmer himself. AFAIK, Python
>> community is on former side, while Lisp one -- on the later. As always,
>> there's no right answer.
> 
> Note I wasn't trying to argue anything, I was actually interested in how the
> behavior is handled in Lisp?  Do you know how the Lisp implementation of
> threads you spoke about handles this case?
> 
> E.g., can the Lisp implementation you are familiar with actually kill such a
> thread blocked on an arbitrary external system or library call?

     That's more of an OS thing.

     Under QNX, the real-time operating system that does almost everything
by message passsing, all operations which block are not only interruptible,
but can be given a timeout.  QNX has a well worked out system for interrupting
system calls and canceling threads in a sound way.  If you really want to
see how this ought to work, look at QNX:

http://www.qnx.com/developers/docs/6.3.0SP3/neutrino/lib_ref/t/threadcancel.html

     This sort of thing isn't used much.  It's for emergencies, like "We just
lost the other CPU in the redundant pair.  Cancel all nonessential threads
and take over control of the rolling mill NOW".  Python doesn't do jobs
like that.

				John Nagle