Mailing List Archive

Embedding python/multi-thread env
I am looking for a suitable scripting language for a multi-threaded
server application. I am wondering if python might be a fit. The
server must be able to run multiple scripts concurrently (in separate
worker threads) and must be able to stop any of these scripts cleanly at
any time. The scripting language must also allow writing C extensions -
I am believe python meets this req. I am not so sure about the threaded
part. If python cannot meet the threading requirement is there a
scripting language that can?
Tcl also seems like a candidate, but all of the Tcl docs i've found
avoids the topic of embedding multiple interpreters in a multi-threaded
application like the plague. Does what i'm looking for even exist?
Any insights are much appreciated.

Aaron Lauinger
Cannon Technologies
http://www.cannontech.com
Embedding python/multi-thread env [ In reply to ]
Depending what you really need. You must know that there is a global
lock between the different Python interpreters. If you write your own
C extensions (really easy with Python), you can release this global
lock during your long computations which dont interract with Python.

See Python/C API Reference Manual, chapter 8.1 "Thread State and the
Global Interpreter Lock".

A+

Laurent.

On Mon, 19 Jul 1999 14:08:31 -0500, Aaron Lauinger
<aaronl@cannontech.com> wrote:

>: I am looking for a suitable scripting language for a multi-threaded
>: server application. I am wondering if python might be a fit. The
>: server must be able to run multiple scripts concurrently (in separate
>: worker threads) and must be able to stop any of these scripts cleanly at
>: any time. The scripting language must also allow writing C extensions -
>: I am believe python meets this req. I am not so sure about the threaded
>: part. If python cannot meet the threading requirement is there a
>: scripting language that can?
>: Tcl also seems like a candidate, but all of the Tcl docs i've found
>: avoids the topic of embedding multiple interpreters in a multi-threaded
>: application like the plague. Does what i'm looking for even exist?
>: Any insights are much appreciated.
>:
>: Aaron Lauinger
>: Cannon Technologies
>: http://www.cannontech.com
>:

---
Laurent POINTAL - CNRS/LURE - Service Informatique Experiences
Tel/fax: 01 64 46 82 80 / 01 64 46 41 48
email : pointal@lure.u-psud.fr ou lpointal@planete.net
Embedding python/multi-thread env [ In reply to ]
Laurent POINTAL wrote in message <37941e27.85316128@news.u-psud.fr>...
>Depending what you really need. You must know that there is a global
>lock between the different Python interpreters.

I believe that you cannot create multiple interepreters in a single
executable.
The python global lock is to prevent *threads* within the interpreter from
stomping on each other's critical sections.

Anyhow.. we have a similar need. Since I am going to create an
interpreter, create threads for each worker, and have them jump into C code
to block waiting for the C++ code to get a client. You might have to do
some tricky synchronization between the two "thread pools" but it's totally
workable.
Embedding python/multi-thread env [ In reply to ]
Rich Salz wrote:

> I believe that you cannot create multiple interepreters in a single
> executable. The python global lock is to prevent *threads* within
> the interpreter from stomping on each other's critical sections.

Sure can; it's part of the API. They still share the global lock, but
they can have completely different sets of modules loaded, etc.

- Gordon
Embedding python/multi-thread env [ In reply to ]
You're right, I wasn't clear enough. You can create multiple interpreters,
but
you still must serialize all python calls -- e.g., don't have two threads
trying to
create an interpreter at the same time.

Gordon McMillan wrote in message <1279107155-5981362@hypernet.com>...
Rich Salz wrote:

> I believe that you cannot create multiple interepreters in a single
> executable. The python global lock is to prevent *threads* within
> the interpreter from stomping on each other's critical sections.

Sure can; it's part of the API. They still share the global lock, but
they can have completely different sets of modules loaded, etc.

- Gordon