Re: Standard Queue status

["Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org>]

Well, like I said, it depends a lot on your relative level of paranoia. :-)

When I used to do flight-critical software, we wouldn't have done anything
with dynamic storage out of fear that somehow, some way, a corner case might
arise that threw the timing off (or something similar) and the box might
crash - or worse. Its also much harder to verify dynamic memory stuff if
you're doing real rigorous testing.

Now that I'm working on programming digital TV boxes in C (with a *real*
crappy, unstable OS! :-) with the only true realtime requirement being
"Don't annoy the user too much" the thought of dynamic memory is a lot less
scary. (Indeed, its being used all over the place and I think its one of the
chief causes of our little box crashing a lot at the moment.) Worst case -
the box crashes & reboots and maybe someone is annoyed that you messed up
their attempt to record a rerun of "Gilligans Island".

Mind you, there's always a variety of product warranty and liability issues.
Not to mention corporate reputation, etc. Hence you still don't want any
instability if at all possible. But its easier to tolerate a potential
source of software errors in some environments than in others.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Ted Dennison" <dennison@telepath.com> wrote in message
news:1oNN7.43862$xS6.73757@www.newsranger.com...
>
> Stuff like that can happen in our system quite easily. For example, a user
who
> knows just enough about the system to be dangerous could theoriticaly
decide
> that the navigational model is behaving too sluggishly for them, and go
into our
> configuration file and bump its iteration rate up to 30Hz where it doesn't
even
> have time to complete before the next iteration. Then they will start to
get
> overrun messages all over the place. Our answer to this is: "Don't do
that". The
> configuration stuff is there for diagnotic purposes, not for casual
twiddling.
>
> ---
> T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>
> No trees were killed in the sending of this message.
> However a large number of electrons were terribly inconvenienced.