[Tinyos-devel] Re-initialization QueueC and PoolC

[Eric Decker]

what I find interesting is a network protocol specification is in some ways
constraining a software system architecture.  That seems a bit off.  Nor do
I think that is the intent of the 802.15.4 protocol definition.  Standard
speak can be odd.  I've been through it.

I think changing the behaviour of Queues and Pools is asking for trouble as
is calling Init again.  The reset is from 802.15.4 and should be handled in
that stack.  The intent I am sure is to put the 802.15.4 stack
implementation back to its initial state.  Not the entire system.

I think the approach where the 802.15.4 stack is told to reset and it does
its clean up is the way to go.

eric
autonomous systems lab
ucsc


On Wed, May 28, 2008 at 8:16 PM, Razvan Musaloiu-E. <razvanm at cs.jhu.edu>
wrote:

> Hi!
>
> On Wed, 28 May 2008, Matt Welsh wrote:
>
> > I'm not quibbling over the name, it's the semantics I'm worried about
> > too. In your original message you said
> >
> >>  Jan wants to return the QueueC and PoolC data structures to their
> >> initialized state, i.e., call Init on them.
> >
> > Which suggested that there is already an 'Init' method of some kind on
> > the Queue and Pool interfaces, though I see now there's not...
> >
> > My suggestion is that there be an 'Init' or 'reset' call on the
> > interface that does two things:
> >
> >   (1) First notifies any clients of the Queue or Pool that a reset is
> > being done (via a signal), giving the clients a chance to free any
> > references on the queue or pool; and then
> >   (2) invokes code within QueueP / PoolP to internally reset the
> > state assuming that the  clients' cleanup was successful.
> >
> > The 'cleanup' signal may be difficult to implement in general;
>
> I'm frequently taking messages from Pools and return them in
> Receive.receive() and then later put back in the Pool the received
> message.
>
> > fortunately I think there are few cases where this will really be
> > needed and it could be left as a default implementation (that could
> > leak memory, but life's tough).
> >
> > The other view is that you're inventing a problem here. Instead Jan
> > should simply not use QueueC or PoolC in the stack implementation, and
> > manage memory directly. It's true that dealing with this in general is
> > pretty difficult and it seems the problem should not be pushed back
> > onto Queue and Pool but rather done in the 15.4 stack.
>
> I agree. The current Queue in Pool are too useful to change them. :-)
> Having other implementations that suite special needs make more sense.
>
> --
> Razvan ME
>
> > On May 28, 2008, at 10:19 PM, Philip Levis wrote:
> >
> >>
> >> On May 28, 2008, at 7:17 PM, Matt Welsh wrote:
> >>
> >>> Sounds like using 'init' is the wrong thing here - really you want
> >>> a 'reset' which has the semantics of reclaiming the memory and then
> >>> initializing the structures to their original state. Handling the
> >>> mechanics of 'reset' would be done by the client of the Queue or
> >>> Pool (in this case the 15.4 stack).
> >>
> >> The name of the operation isn't too important at this point; what's
> >> important is its effect. Pools and Queues can have multiple clients.
> >>
> >> Phil
> >
> >
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>



-- 
Eric B. Decker
Senior (over 50 :-) Researcher
Autonomous Systems Lab
Jack Baskin School of Engineering
UCSC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20080528/b104fd63/attachment-0001.htm