realtime design

Will Stuyvesant hwlgw at hotmail.com
Tue Oct 15 11:44:14 EDT 2002


> [Tim Daneliuk] 
> ...
> There is an inherent problem with the term "realtime" if it is
> not further qualified.  
> ...
> 1) "Hard" realtime - ...
> ...
> 2) "Soft" realtime - ...
> ...

I was looking for a primitive that can be used for modeling *hard*
realtime, but without the ``service completed'' requirement.  ``I
cannot do this in time'' is also acceptable at timeout.  The point
is that the caller should be able to carry on.

> ...
>                  http://www.tundraware.com/Technology/Bullet/
> ...

And you have more interesting stuff there.

> HOWEVER, you said you wanted to "prototype" such a system.
> Depending on how functional your prototype needs to be, Python
> may well be a good choice.  It is relatively easy and quite
> appropriate to *model* realtime systems, hard and soft, in other
> languages.  

Well as you can see in this thread I failed using Python!  Maybe
my requirements are too strict.  For modeling ``ordinary''
function calls a combination of Queue.Queue and
threading.Thread.join(timeout=...) can be used.  But if the
function call winds up doing cpu intensive stuff (for example
pow()) at the C level then the Python threading timeout fails, so
the caller can not carry on in time.  And *that* is essential for
the realtime modeling primitive.  Performance is no issue, the
simulation is allowed to be very slow, as long as it does
implement the primitive correctly.  

If I have more time I am going to look into doing this with
processes instead of threads.  

Thank you for your comments!


'''
QOTD, about modeling

Recession is when your neighbor loses his job. Depression is when
you lose your job.  These economic downturns are very difficult to
predict, but sophisticated econometric modeling houses like Data
Resources and Chase Econometrics have successfully predicted 14 of
the last 3 recessions.
'''



More information about the Python-list mailing list