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: <https://emu.freenetproject.org/pipermail/devl/attachments/20080115/3fa7389e/attachment.pgp>
