David Bolen wrote:
Vsevolod <vselo...@gmail.com> writes:
On Apr 27, 11:31 pm, David Bolen <db3l....@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
--
http://mail.python.org/mailman/listinfo/python-list
