embedded python - cancel "while 1: pass"

Tim Peters tim.one at home.com
Mon Jan 8 02:55:44 EST 2001


[Tim]
> Py_AddPendingCall does not have proper mutual exclusion (the
> comment *says* "critical section" but the code doesn't implement
> one!),

[Warren Postma]
> That sounds easy to add to me! :-)

Hard to say without giving it more thought than I can afford now.  If you
use a platform-specific exclusion method, sure.  If you stick to Python's
portable lock abstraction, though, it *could* be much harder.  For example,
if you reuse the global interpreter lock for this, it creates real problems
for threads Python didn't create (they would have to bootstrap themselves
into having all the crud Python requires before a thread *can* acquire the
global lock).  OTOH, if you create a new lock for this, there may be
potential for deadlock (depending ...).

If it interests you enough to figure it all out <wink>, you should take it
up on the Thread-SIG.

> As for the "portable thread-local-storage" problem, are there any
> other scripting languages out there that are highly multithreaded,
> that we could examine to see how they overcome these things?

Not that I know of.  But note that TLS is basically trivial from a tech
viewpoint:  every threaded platform has *some* reasonable way to spell it.
The problem is that no two platforms spell it the same way, so it's another
configuration (at Python build time) nightmare requiring lots of platform
experts.  And then there's HP-UX, where no two platform experts have ever
agreed on how to do anything involving threads <0.5 wink>.

> (Does a JVM have a means of signalling it's threads?)

A whole different API with every release, trying to make up for that the
previous release's API didn't work <0.7 wink>.  Seriously, Java's thread
.stop(), .resume(), and .suspend() methods were all deprecated, because they
proved to be "inherently unsafe" in practice.  This isn't real surprising:
a thread is cheaper than an OS process largely because the runtime *doesn't*
save enough info to clean up a thread safely, short of the death of the
process it's running in.  The current Java advice should sound familiar by
now:

    Many uses of stop should be replaced by code that simply
    modifies some variable to indicate that the target thread
    should stop running.  The target thread should check this
    variable regularly, and return from its run method in an
    orderly fashion if the variable indicates that it is to stop
    running.

But Java does still support Thread.interrupt(), which can be used to "wake
up" a thread waiting on a Thread.sleep(), Thread.join() or Object.wait().
With enough work, I expect Python could offer much the same.  That's not
what most people seem to want, though (they mostly seem to want to kill hung
I/O operations in threads, and there's not much hope of that ever
happening).

if-you-can't-do-it-in-std-c-the-python-implementation-generally-
    isn't-going-to-be-able-to-either-ly y'rs  - tim





More information about the Python-list mailing list