How robust is Python ?
Cary O'Brien
cobrien at Radix.Net
Fri Jan 5 16:22:36 EST 2001
In article <9354f9$vbi$1 at nnrp1.deja.com>, <rturpin at my-deja.com> wrote:
>In article <mailman.978716227.31692.python-list at python.org>,
> Moshe Zadka <moshez at zadka.site.co.il> wrote:
>> .. in my experience, Python is just as robust as Java.
>> Or are you using a definition of robust other then
>> "crashes very little".
>
>That's an interesting comment. We're planning an "always
>up" application, that launches at boot, runs until next
>restart or shutdown, and does a lot of work in between.
>I'd like to use Python. I've been working under the
>assumption that it is adequately robust for this purpose.
>
>Does anyone want to caution me on this?
>
My experience with using --um-er-- a different popular interpreted
language with clean syntax -- in similar situations is that once
you've got it right it will run forever, provided you don't have any
memory or fd leaks. Or bad ram. So
1) Run it HARD and watch it with top for a LONG time,
under different situations to make sure it doesn't
leak memory.
2) If you can check with lsof and make sure you know exactly
why the open files are open. Filling up disk has been
more frequent than software crashes or running out of
ram.
2) Make sure you can compile the kernel a couple of times on the
platform without any sig-11 errors (indicating bad ram).
3) But to be honest I'm a belt-and-braces kind of guy. So the
important processes are forked off by watcher processes that
will restart them (within limits) if they die. Or you could
start it from /etc/inittab if you want.
But I've had processes running for months before the system
was restarted. I've also had Zope instances up for as long
as the systems stayed up -- months at a time, ending due to
either crummy power or moving furnature.
So you should be able to put something that will run forever.
(As an aside, this has always bugged me. Correctly written software
on good hardware should run forever. It can be done. I've seen it.
Anything less is admitting you've made a mistake.)
Comments? Did I leave anything out?
-- cary
More information about the Python-list
mailing list