On Wed, Sep 22, 2010 at 12:14 AM, Roger Larsson <roger.lars...@ltu.se> wrote:
>> So the fix is to add:
>>
>> default command Timers.startPeriodic[int id](int interval) {
>> ... complain/handle/ignore unexpected call ...
>> }
>>
>
> That this command has to be written feels wrong for three reasons...
> 1) compiler error does not even talk about the need for a 'default',
> >> BlinkC.nc:51: Timers.startPeriodic not connected
> even when being on the right track you easily run inte other compile
> errors that won't help you toward the correct solution
Probably a good idea to add an explanation of the possible fixes
(either add a wiring or a default handler) on the first occurrence of
the error message.
> 2) has to be written
> 3) not in Timers.ncc (shouldn't all Timers.xx commands be in Timers.ncc?)
No - the Timer code has nothing to do with this, it's your code that
has to decide what to do when trying to invoke a non-existent timer.
More paranoid code than TinyOS typically contains might:
- log an error somewhere
- attempt some recovery action
- ...
All of the above depend on the caller, not the callee.
>> Note that it would of course be possible to write an analysis that
>> detected that in this particular program there's no need for a
>> "default" startPeriodic command. However that would be a bad idea (in
>> general at least), as:
>
>> - it makes BlinkC less of a standalone component (the missing
>> startPeriodic command will be needed for some wiring patterns)
>
> But adding this to BlinkC.ncc gives the same problem, shouldn't really be
> added to BlinkAppC.ncc
> Or can the compiler handle several modules defining this function? (each with
> its own unique count series?)
> - this unique() / uniqueCount() stuff just don't feel right...
>
>> - it makes code's correctness quite dependent on exactly what analysis
>> is performed in the compiler to detect when default commands/events
>> are not required (should 'for (i = 0; i < 2; i++) call
>> Timers.startPeriodic[i](...);' work too?)
>
> A lot more likely code would be
>
> for (int i=0; i < uniqueCount("Timers"); i++)
> Timers.startPeriodic[i](...)
>
> This pattern could be statically analysed and code generated. But if not
> wouldn't the compiler need to put a dispatch handling somewhere?
Yes, as I said it could be analysed (2 or uniqueCount() would be
equally easily analysed FWIW). But I'm of the strong opinion that
making code correctness depend on fancy-ish analyses is a bad idea
(fancy analyses are great for optimization or bug-finding, but that's
a separate activity).
> Why not in an automatically generated default function, calling something
> like handle_..._error() in default case?
> And let the user define this 'handle_..._error' function instead!
Because hiding potential errors is bad. And the "default" handler is
this "handle...error" function you want, on a per-module basis.
>
> And finally: Why doesn't isn't the Blink example code use this feature in the
> first place?
Because it doesn't expect to have its timers unwired (and would fail
if they were). Note that some components do have default handlers for
some interfaces, e.g. for optional callbacks (the module signals some
event, but it's ok if no-one cares).
David Gay
_______________________________________________
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
