Python reliability

[Ville Voipio]

I would need to make some high-reliability software
running on Linux in an embedded system. Performance
(or lack of it) is not an issue, reliability is.

The piece of software is rather simple, probably a
few hundred lines of code in Python. There is a need
to interact with network using the socket module,
and then probably a need to do something hardware-
related which will get its own driver written in
C.

Threading and other more error-prone techniques can
be left aside, everything can run in one thread with
a poll loop.

The software should be running continously for
practically forever (at least a year without a reboot).
Is the Python interpreter (on Linux) stable and
leak-free enough to achieve this?

- Ville

--
Ville Voipio, Dr.Tech., M.Sc. (EE)

[Peter Hansen]

Ville Voipio wrote:

I am not building a redundant system with independent
instruments voting. At this point I am trying to minimize
the false alarms. This is why I want to know if Python
is reliable enough to be used in this application.

By the postings I have seen in this thread it seems that
the answer is positive. At least if I do not try
apply any adventorous programming techniques.

We built a system with similar requirements using an older version of
Python (either 2.0 or 2.1 I believe). A number of systems were shipped
and operate without problems. We did have a memory leak issue in an
early version and spent ages debugging it (and actually implemented the
suggested "reboot when necessary feature" as a stop-gap measure at one
point), before finally discovering it. (Then, knowing what to search
for, we quickly found that the problem had been fixed in CVS for the
Python version we were using, and actually released in the subsequent
major revision. (The leak involved extending empty lists, or extending
lists with empty lists, as I recall.)

Other than that, we had no real issues and definitely felt the choice of
Python was completely justified. I have no hesitation recommending it,
other than to caution (as I believe Paul R did) that use of new features
is "dangerous" in that they won't have as wide usage and shouldn't
always be considered "proven" in long-term field use, by definition.

Another suggestion would be to carefully avoid cyclic references (if the
app is simple enough for this to be feasible), allowing you to rely on
reference-counting for garbage collection and the resultant "more
deterministic" behaviour.

Also test heavily. We were using test-driven development and had
effectively thousands of hours of run-time by the time the first system
shipped, so we had great confidence in it.

-Peter

[Ville Voipio]

In article <A_************ ********@telcov e.net>, Thomas Bartkus wrote:

All in all, it would seem that the reliability of the Python run time is the
least of your worries. The best multi-tasking operating systems do a good
job of segragating different processes BUT what multitasking operating
system meets the standard you request in that last paragraph?
Well, let's put it this way. I have seen many computers running
Linux with a high load of this and that (web services, etc.) with
uptimes of years. I have not seen any recent Linux crash without
faulty hardware or drivers.

If using Python does not add significantly to the level of
irreliability, then I can use it. If it adds, then I cannot
use it.
type of rugged use you are demanding. I would google "embedded systems".
If you want to use Python/Linux, I might suggest you search "Embedded
Linux".

I am an embedded system designer by my profession :) Both hardware
and software for industrial instruments. Computers are just a
side effect of nicer things.

But here I am looking into the possibility of making something
with embedded PC hardware (industrial PC/104 cards). The name of
the game is "as good as possible with the given amount of money".
In that respect this is not flying or shooting. If something goes
wrong, someone loses a bunch of dollars, not their life.

I think that in this game Python might be handy when it comes to
maintainability and legibility (vs. C). But choosing a tool which
is known to be bad for the task is not a good idea.

- Ville

--
Ville Voipio, Dr.Tech., M.Sc. (EE)

[Ville Voipio]

In article <te************ ********@powerg ate.ca>, Peter Hansen wrote:

Other than that, we had no real issues and definitely felt the choice of
Python was completely justified. I have no hesitation recommending it,
other than to caution (as I believe Paul R did) that use of new features
is "dangerous" in that they won't have as wide usage and shouldn't
always be considered "proven" in long-term field use, by definition.
Thank you for this information. Of course, we try to be as conservative
as possible. The application fortunately allows for this, cyclic
references and new features can most probably be avoided.
Also test heavily. We were using test-driven development and had
effectively thousands of hours of run-time by the time the first system
shipped, so we had great confidence in it.

Yes, it is usually much nicer to debug the software in the quiet,
air-conditioned lab than somewhere in a jungle on the other side
of the globe with an extremely angry customer next to you...

- Ville

--
Ville Voipio, Dr.Tech., M.Sc. (EE)

[John Waycott]

Ville Voipio wrote:

In article <A_************ ********@telcov e.net>, Thomas Bartkus wrote:

All in all, it would seem that the reliability of the Python run time is the
least of your worries.

I agree - design of the application, keeping it simple and testing it
thoroughly is more important for reliability than implementation
language. Indeed, I'd argue that in many cases you'd have better
reliability using Python over C because of easier maintainability and
higher-level data constructs.

Well, let's put it this way. I have seen many computers running
Linux with a high load of this and that (web services, etc.) with
uptimes of years. I have not seen any recent Linux crash without
faulty hardware or drivers.

If using Python does not add significantly to the level of
irreliability, then I can use it. If it adds, then I cannot
use it.

I wrote a simple Python program that acts as a buffer between a
transaction network and a database server, writing the transaction logs
to a file that the database reads the next day for billing. The simple
design decoupled the database from network so it wasn't stresed during
high-volume times. The two systems (one for redundancy) that run the
Python program have been running for six years.

-- John Waycott

[Alex Martelli]

Tom Anderson <tw**@urchin.ea rth.li> wrote:
...

Has anyone looked into using a real GC for python? I realise it would be a
If you mean mark-and-sweep, with generational twists, that's what gc
uses for cyclic garbage.
lot more complexity in the interpreter itself, but it would be faster,
more reliable, and would reduce the complexity of extensions.
??? It adds no complexity (it's already there), it's slower, it is, if
anything, LESS reliable than reference counting (which is way simpler!),
and (if generalized to deal with ALL garbage) it might make it almost
impossible to write some kinds of extensions (ones which need to
interface existing C libraries that don't cooperate with whatever GC
collection you choose). Are we talking about the same thing?!

So python doesn't use the old SmallTalk 80 SmallInteger hack, or similar?
Fair enough - the performance gain is nice, but the extra complexity would
be a huge pain, i imagine.

CPython currently is implemented on a strict "minimize all tricks"
strategy. There are several other implementations of the Python
language, which may target different virtual machines -- Jython for JVM,
IronPython for MS-CLR, and (less mature) stuff for the Parrot VM, and
others yet from the pypy project. Each implementation may use whatever
strategy is most appropriate for the VM it targets, of course -- this is
the reason behind Python's refusal to strictly specify GC semantics
(exactly WHEN some given garbage gets collected)... allow such multiple
implementations leeway in optimizing behavior for the target VM(s).
Alex

[Paul Rubin]

al***@mail.comc ast.net (Alex Martelli) writes:

Has anyone looked into using a real GC for python? ...
lot more complexity in the interpreter itself, but it would be faster,
more reliable, and would reduce the complexity of extensions.

??? It adds no complexity (it's already there), it's slower, it is, if
anything, LESS reliable than reference counting (which is way simpler!),
and (if generalized to deal with ALL garbage) it might make it almost
impossible to write some kinds of extensions (ones which need to
interface existing C libraries that don't cooperate with whatever GC
collection you choose). Are we talking about the same thing?!

I've done it both ways and it seems to me that a simple mark/sweep gc
does require a lump of complexity in one place, but Python has that
anyway to deal with cyclic garbage. Once the gc module is there, then
extensions really do seem to be simpler to right. Having extensions
know about the gc is no harder than having them maintain reference
counts, in fact it's easier, they have to register new objects with
the gc (by pushing onto a stack) but can remove them all in one go.
Take a look at how Emacs Lisp does it. Extensions are easy to write.

[Jorgen Grahn]

On Mon, 10 Oct 2005 20:37:03 +0100, Tom Anderson <tw**@urchin.ea rth.li> wrote:

On Mon, 10 Oct 2005, it was written:

....

There is no way you can avoid making garbage. Python conses everything,
even integers (small positive ones are cached).

So python doesn't use the old SmallTalk 80 SmallInteger hack, or similar?

If the SmallInteger hack is something like this, it does:

a = 42
b = 42
a is b True a = 42000
b = 42000
a is b False

.... which I guess is what if referred to above as "small positive
ones are cached".

/Jorgen

--
// Jorgen Grahn <jgrahn@ Ph'nglui mglw'nafh Cthulhu
\X/ algonet.se> R'lyeh wgah'nagl fhtagn!

[Peter Hansen]

John Waycott wrote:

I wrote a simple Python program that acts as a buffer between a
transaction network and a database server, writing the transaction logs
to a file that the database reads the next day for billing. The simple
design decoupled the database from network so it wasn't stresed during
high-volume times. The two systems (one for redundancy) that run the
Python program have been running for six years.

Six years? With no downtime at all for the server? That's a lot of
"9s" of reliability...

Must still be using Python 1.5.2 as well...

-Peter

[Tom Anderson]

On Wed, 12 Oct 2005, Jorgen Grahn wrote:

On Mon, 10 Oct 2005 20:37:03 +0100, Tom Anderson <tw**@urchin.ea rth.li> wrote:

On Mon, 10 Oct 2005, it was written:

...

There is no way you can avoid making garbage. Python conses everything,
even integers (small positive ones are cached).

So python doesn't use the old SmallTalk 80 SmallInteger hack, or similar?

If the SmallInteger hack is something like this, it does:

a = 42
b = 42
a is b True a = 42000
b = 42000
a is b False

... which I guess is what if referred to above as "small positive
ones are cached".

That's not what i meant.

In both smalltalk and python, every single variable contains a reference
to an object - there isn't the object/primitive distinction you find in
less advanced languages like java.

Except that in smalltalk, this isn't true: in ST, every variable *appears*
to contain a reference to an object, but implementations may not actually
work like that. In particular, SmallTalk 80 (and some earlier smalltalks,
and all subsequent smalltalks, i think) handles small integers (those that
fit in wordsize-1 bits) differently: all variables contain a word, whose
bottom bit is a tag bit; if it's one, the word is a genuine reference, and
if it's zero, the top bits of the word contain a signed integer. The
innards of the VM know about this (where it matters), and do the right
thing. All this means that small (well, smallish - up to a billion!)
integers can be handled with zero heap space and much reduced instruction
counts. Of course, it means that references are more expensive, since they
have to be checked for integerness before dereferencing, but since this is
a few instructions at most, and since small integers account for a huge
fraction of the variables in most programs (as loop counters, array
indices, truth values, etc), this is a net win.

See the section 'Representation of Small Integers' in:

http://users.ipa.net/~dwighth/smallt...ObjectMemory26

The precise implementation is sneaky - the tag bit for an integer is zero,
so in many cases you can do arithmetic directly on the word, with a few
judicious shifts here and there; the tag bit for a pointer is one, and the
pointer is stored in two's-complement form *with the bottom bit in the
same place as the tag bit*, so you can recover a full-length pointer from
the word by complementing the whole thing, rather than having to shift.
Since pointers are word-aligned, the bottom bit is always a zero, so in
the complement it's always a one, so it can also be the status bit!

I think this came from LISP initially (most things do) and was probably
invented by Guy Steele (most things were).

tom

--
That's no moon!

[Tom Anderson]

On Mon, 10 Oct 2005, it was written:

Tom Anderson <tw**@urchin.ea rth.li> writes:

Has anyone looked into using a real GC for python? I realise it would
be a lot more complexity in the interpreter itself, but it would be
faster, more reliable, and would reduce the complexity of extensions.
The next PyPy sprint (this week I think) is going to focus partly on GC.

Good stuff!

Hmm. Maybe it wouldn't make extensions easier or more reliable. You'd
still need some way of figuring out which variables in C-land held
pointers to objects; if anything, that might be harder, unless you want
to impose a horrendous JAI-like bondage-and-discipline interface.

I'm not sure what JAI is (do you mean JNI?)

Yes. Excuse the braino - JAI is Java Advanced Imaging, a component whose
horribleness exceed even that of JNI, hence the confusion.
but you might look at how Emacs Lisp does it. You have to call a macro
to protect intermediate heap results in C functions from GC'd, so it's
possible to make errors, but it cleans up after itself and is generally
less fraught with hazards than Python's method is.

That makes a lot of sense.

tom

--
That's no moon!