Realtime capabilities?

Tim Peters tim.one at home.com
Sat Sep 22 13:53:51 EDT 2001


[Ben <ben at xyz.net>]
> some of you have probably heard (or even used) Erlang (www.erlang.org)
> -- a functional programming language which is executed by a virtual
> machine.  One interesting property of this VM is guaranteed soft
> realtime execution of the Erlang processes.
>
> My question is whether it is possible to add (soft) realtime
> capabilities to the Python VM with reasonable effort? I'm just curious
> and not being an expert of any of the existing Python implementations I
> thought some of you might have a better understanding of this issue
> and can comment on this?

[Aahz]
> I don't know what Erlang means by "guaranteed".

It's more likely that you need to understand what they mean by "soft".  From
the FAQ,

    http://www.erlang.org/faq/x865.html#AEN896

    10.6. What does soft realtime mean?

    Cynics will say "basically nothing".
    ...

That should tell you how a long critical study of the issue ends <wink>.

Short of that, Erlang supports process-based message-passing concurrency,
where it's not the OS's but Erlang's notion of "process", and Erlang
processes are very lightweight (akin to Stackless Python's microthreads).
Erlang is a functional language implemented via reduction, and where the
Python virtual machine time-slices based on bytecode count, Erlang's
time-slices based on reduction count.  The difference wrt approximations of
real-time is that a single Python bytecode can take anywhere from a dozen
machine instructions to thousands of centuries to complete, while a single
reduction step is always (provided the underlying OS lets Erlang keep
running!) speedy.

This means that an Erlang process (unlike a Python thread) can't hog the CPU
for a long time (provided the native OS is letting Erlang run).  In
addition, the Erlang process scheduler guarantees fairness.  Thus, and so
long as Erlang is getting cycles, each Erlang process is "guaranteed" to get
a timeslice before X seconds have passed (where X depends on lots of stuff,
including the total number of Erlang processes running).  A programmer can
exploit all that to deliver probabilistic bounds on response time.

So "soft" means "no, we can't absolutely guarantee anything, but we've
designed the language from the ground up to make it very likely that what we
deliver in practice will be 'good enough', and provided you program
intelligently in our model".

That's more than Python can say in this area, and that's not surprising
because Python never intended to say anything in this area <wink>.

stackless-fans-should-be-most-attracted-ly y'rs  - tim





More information about the Python-list mailing list