a soft real-time system using python
cliechti at gmx.net
Thu Aug 1 13:43:18 CEST 2002
a-steinhoff at web.de (Armin Steinhoff) wrote in
news:ddc19db7.0208010135.217b551 at posting.google.com:
> 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_
why do you say that?!? it's true that other threads are blocked when you
enter a function in a C extension (the GIL is hold), but all the IO stuff
you find in the library releases the GIL during a blocking operation, so
that threads realy run simultaneous.
> Python threads are not _system level_ threads!!
but realy close...
> PS.: If you need REAL-TIME ... go with QNX!
>> 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.
Chris <cliechti at gmx.net>
More information about the Python-list