[freenet-dev] [freenet-cvs] r17020 - trunk/freenet/src/freenet/node

[Matthew Toseland]

On Tuesday 15 January 2008 21:44, Robert Hailey wrote:
> 
> On Jan 15, 2008, at 2:52 PM, Matthew Toseland wrote:
> 
> > On Tuesday 15 January 2008 16:31, Robert Hailey wrote:
> >>
> >> On Jan 12, 2008, at 3:30 PM, Matthew Toseland wrote:
> >>> Probably better to have separate queues, maybe an array of queues.
> >>
> >> So long as the priority is strict that would make it faster to  
> >> enqueue
> >> items, but not dequeue. In this implementation they are already lined
> >> up in send order. In fact, I think that it would be a much better
> >> optimization to only remove 'x' bytes from the send queue:
> >
> > If the queue gets big the linear search we do when adding will get  
> > slow.
> 
> True. Plus, it would be nice to have some kind of stat about the  
> priority system, e.g. queue 'lengths' (bytes/times) per priority which  
> would be easier/faster with separate queues.
> 
> >> public MessageItem[] grabQueuedMessageItems(long
> >> oneMessageMoreThanThisBytes);
> >>
> >> That would also remove (or help?) the rather odd race condition of
> >> packets requeued while the transmitter is holding all the packets.
> >
> > Not sure I understand this - why would we remove less than a full  
> > packet's
> > worth?
> 
> I think the question is... why would we remove more than a full  
> packet's worth?
> Or more specifically, why do we currently dequeue *ALL* of the  
> packets? I suggest passing in a target size (the packet size).

Ok, sounds sensible, especially if you want to do it. :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20080115/3fa7389e/attachment.pgp