Gerhard Fiedler <lists <at> connectionbrazil.com> writes:
> Maybe his thought was that this is more hidden. I don't know. 

I think that the throw mechanism uses the error handler and any unwinding done
to reach it in flat mode, like longjmp() in C. longjmp() is one of the things
one is expressly warned not to use in an interrupted environment. As you know,
it uses a static data structure (or several). The C++ throw mechanism very
likely uses the same paradigm but in addition to longjmp the structure is hidden
from the programmer so he cannot guard it against a concurrent task. There is no
way to know whether the time between when throw occurs and when the handler is
executed affords any protection to the variables and to the stack involved. If
an interrupt occurs in the same thread and the interrupt thread does anything
related to the throw context (such as, initializing the throw data block upon
entry into the try segment), then really bad things will happen. So unless throw
is specifically thread safe in a compiler I don't think that it can be used in
an interruptible environment.

As I wrote before, you are right, C++ or ADA or whatever is the best for the
project to be used should be used. However I usually deal with very small micros
where this cannot be justified. This reflects my point of view. Additionally,
from what I know about Linux and other embedded kernel code, C++ is avoided like
the plague in a kernel/tight timing etc context by developers. Or has been until
very recently. I think that several of the constructs that make C++ easier to
write create hidden things that interfere with operation on the 'bare metal'
with concurrent issues (as above).

Peter P.



-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist