The reliability of python threads

[Carl J. Van Arsdall]

Hendrik van Rooyen wrote:
>  "Carl J. Van Arsdall" <cvanarsdall at mvista.com> wrote:
>
>   
>> [snip]
>>     
>
> Are you 100% rock bottom gold plated guaranteed sure that there is
> not something else that is also critical that you just haven't realised is?
>   
100%?  No, definitely not.  I know myself, as I explore this option and 
other options, I will of course be going into and out of the code, 
looking for that small piece I might have missed.  But I'm like a modern 
operating system, I do lots of things at once.  So after being unable to 
solve it the first few times, I thought to pose a question, but as I 
pose the question that never means that I'm done looking at my code and 
hoping I missed something.  I'd much rather have this be my fault... 
that means I have a much higher probability of fixing it.  But i sought 
to explore some tips given to me.   Ah, but the day I could be 100% 
sure, that would be a good day (hell, i'd go ask for a raise for being 
the best coder ever!)

> This stuff is never obvious before the fact - and always seems stupid
> afterward, when you have found it.  Your best (some would say only)
> weapon is your imagination, fueled by scepticism...
>
>   
Yea, seriously!


>> try and get a better understanding might be to check data before its 
>> stored.  Again, I still don't know how it would get messed up nor can I 
>> reproduce the error on my own. 
>>
>> Do any of you think that would be a good practice for trying to track 
>> this down? (Check the data after reading it, check the data before 
>> saving it)
>>     
>
> Nothing wrong with doing that to find a bug - not as a general 
> practice, of course - that would be too pessimistic.
>
> In hard to find bugs - doing anything to narrow the time and place
> of the error down is fair game - the object is to get you to read
> some code that you *know works* with new eyes...
>
>   
I really like that piece of wisdom, I'll add that to my list of coding 
mantras.  Thanks!

> I build in a global boolean variable that I call trace, and when its on
> I do all sort of weird stuff, giving a running commentary (either by
> print or in some log like file) of what the programme is doing, 
> like read this, wrote that, received this, done that here, etc.
> A bare useful minimum is a "we get here" indicator like the routine
> name, but the data helps a lot too.
>
>   
Yea, I do some of that too.  I use that with conditional print 
statements to stderr when i'm doing my validation against my test 
cases.  But I could definitely do more of them.  The thing will be 
simulating the failure.  In the production server, thousands of printed 
messages would be bad. 

I've done short but heavy simulations, but to no avail.  For example, 
I'll have a couple systems infinitely loop and beat on the system.  This 
is a much heavier load than the system will ever normally face, as its 
hit a lot at once and then idles for a while.  The test environment 
constantly hits it, and I let that run for several days.  Maybe a longer 
run is needed, but how long is reasonable before determining that its 
something beyond my control?

> Compared to an assert, it does not stop the execution, and you
> could get lucky by cross correlating such "traces" from different
> threads. - or better, if you use a queue or a pipe for the "log", 
> you might see the timing relationships directly.
>   
Ah, store the logs in a rotating queue of fixed size?  That  would work 
pretty well to maintain control on a large run, thanks!

> But this in itself is fraught with danger, as you can hit file size 
> limits, or slow the whole thing down to unusability.
>
> On the other hand it does not generate the volume that a genuine 
> trace does, it is easier to read, and you can limit it to the bits that
> you are currently suspicious of.
>
> Programming is such fun...
>   
Yea, I'm one of those guys who really gets a sense of satisfaction out 
of coding.  Thanks for the tips.

-carl

-- 

Carl J. Van Arsdall
cvanarsdall at mvista.com
Build and Release
MontaVista Software