I stand corrected on return values. I spoke from seeing unmitigated
SUCCESS's everywhere...
As to the "...[not] know what to do with a return value..." thing the
ambassador meant to say, that events (at least in the context we
are discussing) are not called from the client code and thus a
return value is never seen by the client. If I understand correctly
events are an extension of interrupts and need to communicate
to the rest of the program world through shared resources (i.e.,
globals) and semaphores or task control constructs. I was using
the ADC stuff as my model, which is reasonably simplistic.
thx
MS
Philip Levis wrote:
On Nov 16, 2005, at 10:41 AM, Michael Schippling wrote:
events should only return SUCCESS or FAIL.
Stuffing the data into a global of some kind is the one true way,
because events are not called from a context that would
know what to do with a return value anyway...
Anything that uses the ADC dataReady() event would be a good example.
Er, events can and should return much more than SUCCESS or FAIL (e.g.,
Receive.receive()).
Detecting race conditions and managing ownership of globals is tricky.
It's an easy way to introduce unintended component interactions and
dependencies that make maintaining your components (and composing them)
very difficult.
What do you mean, "events are not called from a context that would know
what to do with the return value anyway"? Since I assume he'll be
writing the component that signals the event, it can certainly know what
to do with whatever return value he chooses...
Phil
-------
"We shall not cease from exploration
And the end of all our exploring
Will be to arrive where we started
And know the place for the first time."
- T. S. Eliot, 'Little Gidding'
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
