Python is able to fire off new C threads - no problem.
What I would like to be able to do is have an application embedded with
Python have one of its 'C' threads call Python - ie, raw 'C' code starts
multiple threads, and each one of these threads calling "run_string" or some
other exposed Python API.
Obviously, in the worst case, there could be 2 threads trying to enter the
Python interpreter at roughly the same time - ie, before the interpreter has
set up the protection required for the first thread, the second thread also
enters the interpreter.
Does anyone have any insights into performing this?
[The reason I am asking is that I am looking for a decent method of
"breaking" into the debugger when a Python statement is deemed "insane".
For example, I would like to see a "worker" thread that could monitor the
primary Python thread, and when it deems necessary, it could call a
"set_trace" to allow the debugger to be used. But not withstanding this
requirement, the general answer on threads still interests me]
Second Question:
I am primarily running Python in a GUI environment. What I would like to do
is have a number of "servers" running in the same process. A "traditional"
solution would be to use seperate processes, but I want a single process so
all output is directed to different windows in the same process.
I would like to implement each "server" as a Python thread. However, each
server calls "print". AFAIK, there can only ever be one "sys.stdout". This
means that messages from threads are all sent to the same "device", meaning
all output is mixed and jumbled.
My only solution to this problem is:
* define a "write" method in a "thread_print_control" object.
* assign sys.stdout to this object.
* When "write" is called, get the current thread ID, and redirect the output
to an object specific to that thread.
This implies that:
* as each thread starts, it must tell the "thread_print_control" object what
object to use for this thread.
* That a call the "thread_print_control.write" may need to be protected from
context switches - ie, we can not have another thread take execute while we
are in our "write" code. The standard thread mechanisms can probably help
here.
Does anyone have any comments/better ideas for this problem?
Regards,
Mark (MHammond@cmutual.com.au)