[Tinyos-devel] Packet.clear()

[David Gay]

On 10/17/07, Philip Levis <pal at cs.stanford.edu> wrote:
> On Oct 17, 2007, at 11:04 AM, David Gay wrote:
>
> > On 10/17/07, Miklos Maroti <mmaroti at math.u-szeged.hu> wrote:
> >> If the message to be sent is statically allocated in a component and
> >> its ownership does not change (other than passing via Send.send),
> >> then
> >> Packet.clear need not be called. In this case ALL metadata used for
> >> transmission MUST NOT be changed by the Send implementation.
> >
> > Presumablt this exception should be extended to only returning it via
> > Receive.receive.
> >
> > And in both cases it should be clear that this only applies to "things
> > going to the same comm stack", i.e., if you have 2 Send's, then you
> > must use clear if you don't know that they go the same stack.
> > Hopefully you should be able to switch between Receive and Send for
> > the same comm stack...
>
> This came up on the call briefly. I don't think that you can ever
> safely say that you can switch between Receive and Send, because the
> wiring of those two is outside your control. For example, it's
> entirely possible to take CtpForwardingEngineP and hook its receive
> up to the serial stack while its transmit is up to the radio stack.

Well you can't guarantee that Send isn't hooked up to something that
blinks leds rather than send packets either. It's perfectly fine to
specify that there's some wiring constraints beyond  respecting the
interface types. Especially in a private component for which you're
supposed to be the only one wiring...

David


> Furthermore, this puts the onus on the receive side to clear out
> these fields. Otherwise, they will be as they were the last time send
> was called with that buffer, which might not have been this same
> component. In that way, Receive by itself is not sufficient, because
> it's possible you returned it to a queue, which then another
> component uses for Receive.
>
> I'm not sure what the exact correct usage should be.
>
> Phil
>
>
>