Threads

Terry Hancock hancock at earthlink.net
Wed Jan 3 17:59:03 EST 2001


Thanks for the replies so far, I'm learning a lot.

To clarify a bit -- the kind of "hang-ups" I expect
are ones which involve subtle (or in some cases,
obvious) coding errors, e.g. when a behavior goes
into an infinite loop waiting on an event which
will never happen or which will, but will simply
take too long.  The latter will probably be quite
common. In some cases this sort of behavior may
be designed in -- some behaviors might compete,
with the first one that finishes being used to get
the result.  Generally, though, it just means the
programmer hasn't thought through all possibilities
of the program (as the system gets very complex,
this may be an unreasonable development requirement,
and soft-failure is a better option than rigorous
testing -- kind of like the reason Python has
exception-handling built in).

Behaviors shouldn't be able to access
the operating system (not sure if I can enforce this,
but I'll try to at least make it difficult).

Also, someone pointed out that there is no "pthread"
in fact, I meant to refer to "thread" and "threading",
the documentation mentions "pthread" as an alternate
name for a "POSIX threading" implementation in the
OS.  Hence my confusion, sorry. Also, I'm presently
using Python 1.5.2 so I may not know about newer stuff
than that.  I guess I'll have to upgrade to use micro
threading, for example.

Mike Fletcher wrote:
> With the current uthread (micro-thread) system, you can kill a micro-thread,
> but only if you can get the scheduler code to run.  If a micro-thread hangs
> _in C code that hasn't released the Python interpreter lock_ then you can't
> kill the thread (and your whole micro-threads simulation is hosed, as the
> scheduler will not run any more).

That would be bad, but shouldn't be an issue, as there shouldn't really
be any such code used in this system. (Except for special "I/O"
behaviors
which are part of the environment and will be tested a lot harder).

> Python code in a micro-thread that's taking forever to complete (such as a
> long-running AI computation, or a thread that's blocking on a lock) can be
> killed easily using the provided methods of the thread object.

That's the capability I need.

> -----Original Message-----
> From: Donn Cave
> To: python-list at python.org
> Sent: 1/3/2001 2:15 PM
> Subject: Re: Threads
> ...
> >From what I have heard of the stackless microthread system, you
> won't get the `processes that "hang up" can just be killed' part
> of what you want there, at least not for all causes of hanging up.
> Honestly, I guess you won't get it from Python threads either,
> because there is no provision in the API for killing a thread, but
> at least the process will continue, because these threads go down
> to the operating system level where the usual hanging up happens.
> ...
> 
> --
> http://www.python.org/mailman/listinfo/python-list

-- 
Terry Hancock
hancock at earthlink.net




More information about the Python-list mailing list