[Tinyos Core WG] Proposal for VariableSizedQueueC component

[Kevin Klues]

I have no problem with this at all..... I just came across the need
for a bigger queue and was trying to come up with a general way of
creating one.

Kevin

On 9/18/07, Philip Levis <pal at cs.stanford.edu> wrote:
> On Sep 18, 2007, at 10:05 PM, Kevin Klues wrote:
>
> >> How about calling it QueueP.nc? Also, would this also make sense with
> >> PoolP?
> >
> > The problem is that we also need to redefine the Queue interface to
> > contain a new parameter, not just tack it onto a new QueueP component.
> >
> > We need Queue to look like this now:
> > interface Queue<t, queue_size_t> {
> >   command queue_size_t size();
> >   command queue_size_t maxSize();
> >   command t element(queue_size_t idx);
> >   ....
> > }
> >
> > So the question is whether we want to leave QueueC backwards
> > compatible with the way it was or not.
>
> I think breaking QueueC is a bad idea; this is the first time its
> limited size has come up. Another, perhaps simpler approach might be
> to just have a BigQueue interface, which is the same but with a
> uint16_t. I mean, there really are only 4 possibilities for the
> parameter -- uint8_t, uint16_t, uint32_t, and uint64_t -- and the
> largest two seem very unlikely. The only reason to go through the
> level of indirection that a typed component introduces is code reuse;
> I certainly hear enough grumbles about the levels of indirection, and
> this one might be a wash. I personally kind of liked that QueueC was
> so simple; John Regehr recently proved it correct.
>
> Phil
>
>
>


-- 
~Kevin