[Tinyos-host-mote-wg] Re: [Tinyos-2.0wg] AcquireData error() event?

[Philip Levis]

On Tue, 2005-09-06 at 16:48 -0700, Gilman Tolle wrote:
> Why does the AcquireData interface signal a separate error() event,
> while the AMSend interface signals the normal done() event with an
> error_t parameter?
> 
> It seems like TOS2 should have a consistent answer to this question:
> do split-phase commands signal a different event when they fail?
> 
> To propose an answer, didn't we decide a while ago that having
> multiple return events from a single split-phase command makes it
> easier to create locking bugs?

There is a consistent answer. However, that doesn't mean that everything
behaves in the same way, as there can be differing considerations and
trade-offs. IIRC, this question was asked at the NEST retreat in May.

The distinction lies in what you do with the result of a failed request.
Pros and cons for the two approaches:

1) Putting error_t in completion event:
    Pros: Simplifies completion code: only one code path (e.g., for
locking)
    Cons: Chances are code will ignore the error_t

2) Putting an error in a separate event:
   Pros: Makes sure that developer acknowledges error condition
   Cons: Requires two code paths

I'd argue that for sensor readings, the Con for 1) is much greater than
for sending packets. In the latter case, you tried sending a packet and
it didn't work for some reason. This is externally observable ("Why
isn't that node sending any packets?"), and given the lossy nature of
networking in general a single failed packet shouldn't cause code to
break.

In the sensor case, you'll have bogus data, which you'll blindly store.
This could go on for a long time before anyone notices anything funny
(e.g., if you are writing it to non-volatile storage).

Specifically, AcquireData and ADCs are interfaces that *generate* data,
which could potentially drive many routing, application, or algorithmic
decisions. Therefore, code should explicitly deal with error conditions.

Phil



_______________________________________________
Tinyos-2.0wg mailing list
Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg