Hi Viv,
I did not express myself correctly, sorry, I should've said "might be interrupted" instead of "can be interrupted", for I do not know the answer, thus I assume that either way is possible and
try to code accordingly (not sure if I succeeded, but I did not see any problem in my program after more than a year of running 24/7, only down time is for upgrades or network problems).
Good question anyways, unfortunately I do not have the answer
>Hi,
>>
>
>...just take into account that the code (AFAIK) can be interrupted by either event (the timer inturrupting the oncomm or the oncomm interrupting the timer)
>>
>
>Sort of off thread, but I'm wondering if that is true. I'd expect a higher priority interupt to occur during the execution of a lower priority one - but not the reverse. Admittedly I'm thinking in terms of hardware interupts here but the same logic would surely need to be present in this scenario. The alternative would surely be chaos <g>. I also don't know which of the above would have the highest priority but I'd bet on the Comm event.
>
>Regards,
>Viv
"The five senses obstruct or deform the apprehension of reality."
Jorge L. Borges?
"Premature optimization is the root of all evil in programming."
Donald Knuth, repeating C. A. R. Hoare
"To die for a religion is easier than to live it absolutely"
Jorge L. Borges