On Sat, Oct 23, 2010 at 12:25 AM, Dongyu Yang <yangdy.n...@gmail.com> wrote:
> I have tested this: when one Node (A) happened this phenomenon, I reduce
> the dissemination rate
> to once ever 10 seconds, and stop the other Nodes, this phenomenon exist
> still, the Node (A) can
> only receive the dissemination command, but can never send out data!
> I think it is not cased by the channel capacity, but because in Send.send()
> the
> clientPtrs[client] be set NULL;
>
> command error_t Send.send[uint8_t client](message_t* msg, uint8_t len) {
> ......
> if (call SendQueue.enqueue(qe) == SUCCESS) {
> if (radioOn && !call RetxmitTimer.isRunning()) {
> post sendTask();
> }
> clientPtrs[client] = NULL;
> return SUCCESS;
> }
> ......
> }
> if it do not deal with the EBUSY and FAIL state in the else condition, it
> will remain NULL. So the
> next when call Send.send() it return EBUSY, because the "clientPtrs[client]"
> only be reseted
> in the "void packetComplete()" function which be called in the "event void
> SubSend.sendDone()"
> as below:
>
> command error_t Send.send[uint8_t client](message_t* msg, uint8_t len) {
>
> ......
>
> if (clientPtrs[client] == NULL) {
> dbg("Forwarder", "%s: send failed as client is busy.\n",
> __FUNCTION__);
> return EBUSY;
> }
> ......
> }
>
>
> void packetComplete(fe_queue_entry_t* qe, message_t* msg, bool success) {
> ....
> if (qe->client < CLIENT_COUNT) {
> clientPtrs[qe->client] = qe;
>
> ....
> }
> ....
> }
> because the command SubSend.send() return not SUCCESS, so the event
> SubSend.sendDone() will not signal, so the "clientPtrs[client]" remain NULL.
The return value is either FAIL or EBUSY in that else block.
If it is FAIL, we should wait until the condition that resulted in
FAIL is repaired. If it is EBUSY, that means we should wait
until sendDone.
I think we are handing the EBUSY case properly.
There is a possibility that we are not handing all the possible cases
that can result in FAIL.
I understand posting sendTask solved your problem but I want to
understand why it works and if there is any FAIL condition that we do
not handle properly before committing the fix. Do you know what return
value you were getting when this bug is triggered? If it is FAIL, what
caused that FAIL return value?
- om_p
_______________________________________________
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
