First forking and then multithreading the interpreter?

[Bram Stolk]

Hello,


Does anyone know what bad things could happen if you first fork python,
and then create threads in one of the processes? I would assume this is
possible.

However, I get very weird behavior:

I can run my python app in multiprocess mode.
I can run this same app with multithreading.
But if I combine them by doing a coarse grain multiproc, and finer
grain multithreading, the app misbehaves (some tasks not performed).

The forking is implemented in C code, wrapped by SWIG as a Python object.
After the fork, I have 3 processes running (OpenGL|Performer processes:
APP,CULL,DRAW).
In the app, I create a thread to run concurrently with the main python
thread -> things are not performed well.

If I leave out the fork step: all is well (both in multithread and
singlethread mode)

If I leave out the threading step: all is well (both in multiproc and 
single proc mode)

I don't have details on the fork step, because it is done in the
OpenGL|Performer library I link against. The multithreading step
is performed by the thread.start_new_thread method.

Also, I have no race-conditions, and do not perform concurrent
access to shared resources.

I use SMP linux and python 2.2.1

thx,

  Bram


-- 
------------------------------------------------------------------------------
 Bram Stolk, VR Specialist.
 SARA Academic Computing Services Amsterdam, PO Box 94613, 1090 GP  AMSTERDAM
 email: bram at sara.nl   Phone +31-20-5923059  Fax +31-20-6683167

 "I heard if you play the NT-4.0-CD backwards, you get a satanic message."
 "Thats nothing, if you play it forward, it installs NT-4.0"
------------------------------------------------------------------------------