python's threading has no "interrupt"?

Peter Hansen peter at engcorp.com
Wed Dec 3 09:22:12 EST 2003


Aahz wrote:
> 
> In article <9btu91-s04.ln1 at beastie.ix.netcom.com>,
> Dennis Lee Bieber  <wlfraed at ix.netcom.com> wrote:
> >
> >There's the first point of departure: Python threads (as long as you
> >aren't in a C language number crunching extension) are preemptive
> >scheduled, on something like a 10-20 byte-code interval. Cooperative
> >basically means /you/ had to handle the scheduling of threads; in
> >Python you don't, it happens automatically.
> 
> Actually, that's not really correct.  Cooperative threading means that
> there's no way to force a thread to yield up a timeslice, which is
> precisely the way Python works, because any bytecode can last an
> arbitrarily long time (consider 100**100**100).  It is true that the
> Python core does switch between bytecodes, but that should not be
> considered preemptive in the traditional sense.  

I would say that Python is actually much closer to preemptive in the 
traditional sense than it is to being cooperative.

Yes, some bytecodes could have almost unbounded duration under some
(perverse?) conditions, but the parallel between bytecodes and opcodes
in machine language is very strong, and you can't interrupt (most)
machine opcodes either... they just take much less time to execute,
and their durations generally span many times fewer orders of 
magnitude...

Thinking of Python as preemptive, but in a "softer" sense, is in my
opinion the most useful view...

-Peter




More information about the Python-list mailing list