On 8/19/2011 10:28 PM, David Barbour wrote:
On Fri, Aug 19, 2011 at 8:24 PM, BGB<[email protected]> wrote:
if a message is equivalent to a method call, then it is equivalent to a method
call...
Yes. But it's hard to make a point with a circular argument.
keep in mind that this statement has one of multiple possibilities,
depending on what one means by the term message.
either, it is a reference to a method call, having no obvious
differences, or it is referring to something different, and the "issues"
with this other thing are not an issue in the context of a method call.
there are worse ways to do things than by passing messages
Certainly! We could do a lot worse than messaging. But we could also
do a lot better.
potentially.
a much more notable problem is that, in the case of many systems,
there ends up being tight coupling between components.
I agree that this is a problem, and one that shows up repeatedly at
many different scales as you indicate. But this is not a problem with
messaging, nor one solved by messaging, so I'm having some difficulty
understanding why you bring it up in context.
if code is sensitive to things like message ordering, ... then this
seems more likely a result of how tightly coupled/..., rather than of
the underlying communication used between the components.
it is much like asserting that because UDP packets arrive out of order,
may come as duplicated, may be dropped, ... then UDP packets are for
this reason unusable for network communication (or that datagram based
communication is itself inherently flawed).
IRL, many protocols are built on top of UDP, and as such are designed to
deal with matters of packet loss/duplication/ordering/... (infact, it is
more often protocols built on TCP which have problems, as they are less
often designed to deal with the occasional stalls/resets/... which may
result in network communication).
similarly, a well designed API is also designed to hold up to some level
of abuse:
being misused (calls before initialization, botched initialization);
being fed bad input (bad data values, random NULL pointers, maybe
garbage pointers, ...);
...
an API should then put up its best effort in behaving "sanely" even if
the code trying to make use of it is at fault, and generally code which
blows up due to bad input is still implicitly at fault for failing to
handle these things gracefully (corrupt data should cause the input to
be rejected, not result in a crash).
granted, these sort of events can also be a helpful debugging aid (for
example, it is fairly common to log things/... in these cases to help
try to identify whatever is going wrong in the program).
sometimes, it even makes sense to insert intentional crashes, mostly to
help bring the event to the attention of the debugger (and often closer
to the source of the problem), but this needs to be weighted carefully
against trying for graceful handling (some types of problems are much
more serious than others).
sometimes, this does lead to some level of pedantic error checking/...,
which could be argued to potentially reduce performance, but oh well...
sadly, from a security prospective, a lot of my code is fairly weak
(sadly, there are a great many places where one could likely try for
buffer-overflow exploits or similar). although, on a partial upside:
MSVC itself seems to insert a lot of "security token" code into its
generated output, I suspect as a means to try to protect against buffer
overflows at a more basic level.
ASLR can potentially help here some.
granted, ultimately a lot of this will likely need to be addressed.
as, despite their efforts, exploiting buffer overflows has generally
been one of the major ways people go about rooting the XBox and XBox360
and similar.
I do favor content-centric discovery approaches to the highest levels
of decoupling, and interface or duck types for everything else. I'm
thinking to make module imports pattern-based (augmented with
arbitrary validation guards) for content-centric discovery.
yeah. I often try to decouple things where possible, as I am not really
a fan of rigid or inflexible code.
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
