What happened in fact was that a graphics plotting function for
monitoring got called twice frorm a different thread, due to an 'old'
instruction inadvertently left. Due to the quasi random nature of the
incoming data streams, this happened rather very sparingly. As the
plotting itself involves qu
malv wrote:
> After one of those 'hangs', with some luck,
> I was able to spot the cause of the trouble: a piece of old code that
> wasn't supposed to be out there! Really dumb.
> FYI, to my surprise, Python really quit. No more CPU time, no message,
> nothing. I can't recall having seen this befor
Hi Peter,
Thank you for your extensive reply.
In the meantime, I solved the problem. I had started out to trace the
path of the randomly arriving external data through the different
threaded processing stages. After one of those 'hangs', with some luck,
I was able to spot the cause of the trouble:
malv wrote:
> How would you approach the following?
> In a multithreaded realtime data acquisition system (all python v2.4),
> after hours of running without a snag, without warning python hangs at
> once without leaving any error message or error traceback at all. After
> the incident, the OS itse
How would you approach the following?
In a multithreaded realtime data acquisition system (all python v2.4),
after hours of running without a snag, without warning python hangs at
once without leaving any error message or error traceback at all. After
the incident, the OS itself (linux) appears to
