Can a delay between canSend returning true and calling sendStart cause problems?

[pb66]

Whilst debugging an issue with a sketch using JeeLib a couple of questions have cropped up that I wonder if you can clarify.

the first is in the title, in the comments in rf12.cpp it says (in so many words) to use sendStart immediately after canSend returns true. and the sendNow function also does exactly that. But (for example) your RF12demo example uses the following code

if (cmd && rf12_canSend()) {
        activityLed(1);

        showString(PSTR(" -> "));
        Serial.print((word) sendLen);
        showString(PSTR(" b\n"));
        byte header = cmd == 'a' ? RF12_HDR_ACK : 0;
        if (dest)
            header |= RF12_HDR_DST | dest;
        rf12_sendStart(header, stack, sendLen);
        cmd = 0;

        activityLed(0);
    }

is that ok to do so? Can anything change in the time it takes to do that stuff that might block the sendStart, or cause a conflict that might cause a perceived "lock up" that can be overcome by reinitializing the rfm like what is reported in issue #92 ?

The second question is regarding the recommendation or need to call the recvDone function "periodically" even when only using a device to send data. Is that comment still valid with the use of sendNow since that calls recvDone each time canSend returns false until a true is returned. Only if canSend always returns true first time would there be a period where revcDone isn't called when you're sending data regularly.

How often is periodically? is there any advantage to calling it at a particular time?

Is there any advantage to calling recvDone immediately before the send code block or even as part of the test to enter the send block?

And just for curiosity, why does the RF12demo not use sendNow? is it because you are avoiding blocking the main loop or does this code just pre-date that function?

Any clarification would be great, thanks.