any issues with long running python apps?

[CM]

     Yesterday, I was running a CNC plasma cutter that's controlled
by Windows XP.  This is a machine that moves around a plasma torch that
cuts thick steel plate.  A "New Java update is available" window
popped up while I was working.  Not good.

<Clippy> Hi, it looks like you're attempting to cut something
with a plasma torch.  Would you like help?

(_) inserting a steel plate to cut

(_) severing the tip of your finger

[ ] Don't show me this tip again.

-tkc

Brilliant. (I almost think you should have gone with
far more than severing the tip of the finger, but then
you'd lose that killer play on words at the end).

 

[Maria R]

I can second the stated opinion that Python per se is stable enough.
We deliver production systems running 24/7 with uptimes counted in
several months
and from what I can see, compared to the OP's app, ours is vastly more
complex.

The only Python-related issue we have encountered so far, wrt to
stability, is how
timers are working. Extensive creation of timer threads have locked up
after some
indeterminable time. We found that the issue was probably related to
some update in
Windows at the time.
We do not know whether this issue is resolved (we encountered it back
in Python 1.4)
and we rewrote our code to use timers differently.

I also second that partitioning the solution in working (server) parts
and GUI (client)
parts is important.

I do not second the generally outspoken distrust in Windows. Indeed, I
would prefer *nix/*nux
but in our case, stability concerns is not one of the issues behind
that.

We use threading to a certain extent (in addition to partioning into
processes). One approach we have,
and have shown very useful to gain stability, is to use Exception
handling carefully and extensively.
We catch *every* exception, report and counteract but do not allow the
process/thread to die.
This is not a trival approach, by no means, but when one know the app
sufficiently, it can be applied
with good results.

Just my 2 c
//Maria

 

[Les Schaffer]

thanks to all for the replies.

the Windows memory fragmentation was one of the "i didn't know that"
items. we will use 64-bit Windows OS if the job happens.

agree with all the other suggestions: multiple threads for data and GUI,
etc. Also, might push for Linux even though the company is Windows-only
presently.

but thinking about the issue some more as well as everyone's comments,
have decided to proceed cautiously and let the client decide first that
they really need this app regardless of guaranteed Windows-based uptime.

Les

 

[Stefan Behnel]

Les Schaffer, 16.07.2010 15:07:

agree with all the other suggestions: multiple threads for data and GUI,

The way I read it, the suggestion was to use separate processes, not
multiple threads. That's a pretty important difference.

Stefan

 

[Les Schaffer]

Les Schaffer, 16.07.2010 15:07:

The way I read it, the suggestion was to use separate processes, not
multiple threads. That's a pretty important difference.

check. processes, not threads.

Les