[Tinyos-devel] ENOMEM in TinyError.h

[Matt Welsh]

So, do we have any conclusion on this?

I don't agree that ESIZE, EBUSY, or FAIL conveys the right information  
to higher layers. We have a choice of whether to have a smaller number  
of error codes that could each be interpreted in different ways, or  
defining error codes that have specific, well-defined meanings. The  
advantage is that it is, in my opinion, easier to write correct  
software when the error codes mean something useful. The disadvantage,  
as Miklos points out, is that higher layers may not want to deal with  
so many error conditions.

In my opinion, none of the current error codes directly indicate the  
condition that a resource required to complete an operation is not  
currently available. Given that sensor nets often run in resource- 
constrained settings this would seem to be a useful thing. Phil argues  
correctly that we should avoid reliance on dynamic resource allocation  
in the core, but not providing an error code doesn't make the problem  
go away.

Matt

On May 6, 2008, at 12:55 PM, Philip Levis wrote:

>
> On May 6, 2008, at 9:46 AM, Miklos Maroti wrote:
>> Hi All,
>>
>> We should not increase the number of faulire codes, because then  
>> other
>> code need to be aware of more error codes, especially if intermediate
>> components blindly pass out internal errors to the caller. We already
>> need complicated error handling logic at certain places, and with  
>> more
>> error codes this just gets worse. So please try to use FAIL or ESIZE.
>>
>> The real question should be: what actions do you think the caller is
>> going to do based on the return value. I can see the following usage
>> scenarios:
>>
>> SUCCESS: memory was allocated
>> EBUSY: call me back shortly because I am busy, and then I will  
>> process
>> your request
>> ESIZE or FAIL: have no or too little memory, you should try to live
>> with this
>>
>> By the same token, I do not see the difference between EBUSY and
>> ERETRY: the user should do the same no?
>
> The semantics of an error code are not independent of the interface
> issuing them.
>
> EBUSY denotes that the component was in the middle of doing something;
> ERETRY, in contrast, can just denote that something went wrong and you
> should retry. I'd be surprised for EBUSY to be signaled in a
> completion event, while the one use of ERETRY is in the CC2420 stack,
> when something goes wrong and it doesn't get an SFD on transmission.
>
> Phil
>
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel