Hi Phil
I think my original description is not very precise, actually it is not
the deadlock. However, according to my and Guillermo's description, I
think the buffer should be released even if the endPacket argument is
fail or error. Because, without the releasing, the current buffer,
which is not swapped and still locked, will keep receiving subsequent
byte stream, but this buffer will keep all following bytes out of door...
I think perhaps the fix in the body of endPacket() can remove this
suspicious problem...
async event void ReceiveBytePacket.endPacket(error_t result) {
**********************
if (postsignalreceive){
post receiveTask();
}
else {
releasing the current buffer here
}
}
Regards
Peng
Philip Levis wrote:
> On Aug 19, 2009, at 10:51 AM, Guillermo De Cesco wrote:
>
>
>> Hi,
>>
>> I was digging throw the code and I seems that you are rigth (Peter).
>> It seems that the buffer should be release even
>> if the endPacket argument is fail or error. The case of
>> receiveTaskPending == TRUE isnt really a problem I think
>> because the only situation this can happens is if another async
>> event endPacket cames before you process the pending receive task;
>> in which the receive state will be well defined.
>>
>> -Bill
>>
>
> Can someone describe a series of bytes that will cause this case to
> occur? My (possibly incorrect) reading of it is that you might drop a
> packet.
>
> Phil
> _______________________________________________
> Tinyos-help mailing list
> [email protected]
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
