a soft real-time system using python

[Armin Steinhoff]

anton wilson <anton.wilson at camotion.com> wrote in message news:<mailman.1028134302.18143.python-list at python.org>...
> On Wednesday 31 July 2002 12:33 pm, anton wilson wrote:
> > O
> >
> > > A realtime system places an upper bound on all operations, but the very
> > > nature of Python makes this impractical if not impossible.
> > >
> > > An interaction between Python's handling of the GIL and the platform's
> > > pthread library is going to be the least of your problems if you
> > > actually intend to deliver a system which gives realtime guarantees on
> > > Python programs.
> > >
> > > Jeff
> >
> > If the soft-real-time system we use makes simple function calls and only
> > uses simple datatypes and possibly tuples, what are some of the potential
> > pitfalls we could run into? I understand the deallocation issue and the
> > garbage collection issue. (Does garbage collection have to be enabled?) Can
> > we somehow get an idea on the worse case time delays in python using only
> > simple function calls and assignments with small tuples and simple
> > datatypes?
> 
> 
> For further information, we're already having a certain problem where python 
> threads seem to drastically decrease performance in the middle of the program 
> for around a second. Garbage collection has been disabled, but it's possible 
> that there is some other behind-the-scenes work that Python is doing.

If you are using extensively dictionaries ... Python is using then
extensively malloc of your syetem, that means any performance issues
of the malloc lib will be visible.

Have also in mind that blocking IO calls are blocking the _whole_
interpreter!
Python threads are not _system level_ threads!!  

Armin

PS.: If you need REAL-TIME ... go with QNX!
http://www.sf.net/projects/pyqnx


> What 
> other things should we be worrying about? I need a more complete 
> understanding of what can happen or is happening that would affect consistent 
> running of a python program.
> 
> Anton