[Tutor] Embedded Python on different versions of Windows.

[BELSEY, Dylan]

Using Python 2.1.1

Hi List,
	I am still working on embedding Python within C++ and have almost
reached wits end with a particular issue.  At the moment I initialise the
Python Interpreter within a C++ class (ScriptInterface) using the standard
Py_Initialise().  The class has a method called Update_10Hz, which is called
by an EventServer (CORBA) every 100 ms.  Within this method I use standard
commands such as PyRun_SimpleString() and PyRun_SimpleFile() to run a python
script file.
	I have profiling code within the Update_10Hz() method to measure the
time it takes to run a cycle.  The problem that I am encountering is that on
a Windows NT box I get good consistent timing results (eg 20 ms for a
particular script).  When I move the exact same code onto a Windows 2K box
with dual processors, I get sporadic fluctuations in the time it takes to
execute the method, sometimes blowing out to values in the order of seconds.
	By profiling the internals of the method we find that sometimes, the
greatest amount of time is taken by the PyRun_SimpleFile() command but I am
not sure whether this is a function of the command having to do the greatest
amount of working within the method as it has to call the script file and
then execute it and therefore Python is being scheduled (??) out, or whether
it is something else on the system.
	We have also tried setting priorities of various threads,
particularly elevating the thread that executes the Update_10Hz() and many
other strategies, such as streaming the script file into a buffer before it
is executed, but to no avail.
	After all this explanation, my question is whether anyone has seen
this similar behaviour between different flavours of Windows, where embedded
Python runs differently, and if so what is causing it.  Alternatively, if
anyone has any ideas as to possible causes or fixes or any discussion on the
topic, that would be greatly appreciated.
	By the way, the script makes calls back into the C++ code by way of
a module I have created using SWIG.  We have tested these module calls as
possible sources of error and have confirmed that they are not.
	
	Thanks for your time,
		Dylan