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

Vsevolod vseloved at gmail.com
Wed Apr 29 08:44:38 EDT 2009


On Apr 28, 11:49 pm, David Bolen <db3l.... at gmail.com> wrote:
> Vsevolod <vselo... 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?
>
> -- David

The behavior up to some detail is described here: http://www.sbcl.org/manual/Threading.html

Overall, if this issue comes up important, it is possible to either
get the more detailed explanation from the developers, poke in the
source code or implement the needed behavior yourself. Basically, you
can't know the precise semantics and corner cases of all the language
and implementation constructs you use (especially, when speaking about
libraries, which threading definitely is both in lisp and python).

Moreover, in this case thread-killing semantics is largely defined by
the underlying system (if we are talking about native threads), and
those systems (like Unix) somehow happen to function :), or can be
defined arbitrarily, if we consider green threads. So the answer, that
it can be only poorly specified, IMO, is just an indulgence from
implementing the operation.

Best regards,
Vsevolod



More information about the Python-list mailing list