<div class="gmail_quote">On Wed, Dec 21, 2011 at 11:19 AM, hbd666 <span dir="ltr"><<a href="mailto:happybrowndog@hotmail.com">happybrowndog@hotmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<snip><br>
<br>
In my experience implementing Option 1 in another project, I know that Python suspends<br>
execution until the DLL function calls return, but I did not launch the DLL on a thread.<br>
I expect that if the DLL were launched on a thread, a function call into the DLL will still<br>
suspend Python.  Maybe someone can tell me if this is true?<br>
<br>
Option 2 is of most interest to me, but how shall I handle the Python GIL when the Renderer<br>
runs its main loop?  Will the main loop be unaffected because Python interpreter is embedded<br>
in a thread?</blockquote><div><br></div><div>When extending Python (as option 1 would do), the extension would block all Python threads if called from Python (though c-threads created by the module would not block Python). You can explicitly release the GIL during your C code's execution, which would cause only the thread actually making the call to be blocked (as it is actually running the C code), but other Python threads would still be able to run.
</div><div><br></div><div>When embedding Python (as option 2 would do), the embedding program will not be affected by the GIL unless it explicitly acquires the GIL (which is must do before accessing Python).</div><div><br>

</div><div><br></div><div>Via the Python API functions you can acquire and release the Python GIL as needed. The only rule is that you must hold the Python GIL should you wish to access any part of the Python interpreter (function calls, variables, etc) [note: technically you don't HAVE to, but you run a high risk of data corruption and segfaults from the race conditions which would exist]. </div>

<div><br></div><div><br></div><div>Either option should work fine.</div><div><br></div><div>In case of option 1:</div><div><ol><li>Import the C module.</li><li>The C module sets up some defaults for the render.</li><li>The C module creates its render thread (which is unaffected by the GIL, but probably needs other locks around global variables).</li>

<li>The C module returns to Python.</li><li>The Python GUI calls into the C module to change settings (which probably need to acquire short-term locks)</li></ol></div><div>An alternative would be:</div><div><ol><li>Import the C module.</li>

<li>The C module setups up some defaults.</li><li>Create a Python thread to call the C module's render loop.</li><li>The render loop thread releases the GIL and continues as above.</li><li>The main Python thread continues as above.</li>

</ol><div><br></div>For option 2:</div><div><ol><li>Initialize any needed variables for the system.</li><li>Start a new thread for loading and executing Python.</li><li>Have the main thread start the render loop.</li><li>

Have the Python thread startup up Python.</li><li>Continue as in the first case above.</li></ol></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888"><br>


<br>
-- <br>
<a href="http://mail.python.org/mailman/listinfo/python-list" target="_blank">http://mail.python.org/<u></u>mailman/listinfo/python-list</a><br>
</font></span></blockquote></div><br>