[Tinyos-devel] ENOMEM in TinyError.h

[David Moss]

Dynamic memory allocation occurs all the time in TinyOS, with non-volatile
memory.  Users regularly run out of memory to allocate on both internal and
external flash. 

Most times it's enough to know that an operation didn't succeed, and respond
to that failure appropriately. Other times you need to know why, especially
when debugging. Code doesn't need to handle every error code for every call,
but having the option to access that level of detail can be useful.

Undocumented error codes are defined in custom applications.  Can we suggest
end users define error codes above 128 to avoid conflict with an evolving
TinyOS baseline?

-David




-----Original Message-----
From: tinyos-devel-bounces at millennium.berkeley.edu
[mailto:tinyos-devel-bounces at millennium.berkeley.edu] On Behalf Of Matt
Welsh
Sent: Wednesday, May 07, 2008 5:47 AM
To: Philip Levis
Cc: TinyOS-Devel list; Miklos Maroti
Subject: Re: [Tinyos-devel] ENOMEM in TinyError.h

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

_______________________________________________
Tinyos-devel mailing list
Tinyos-devel at millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel