Why can't we just construct the main table before the summary? On Tue, Aug 01, 2006 at 08:23:42AM -0500, David Sowder (Zothar) wrote: > David 'Bombe' Roden wrote: > >On Sunday 30 July 2006 15:42, David Sowder (Zothar) wrote: > > > > > >>Perhaps it's a lot more work and harder to do, but I think it would > >>be much better to fix the corner cases with the Hashmaps used by > >>node.getPeerNodeStatusSize() rather than calculating it for every > >>/darknet/ page load. Part of the idea of > >>node.getPeerNodeStatusSize() was for the information to be both > >>accurate and available to other parts of the node at near zero CPU > >>cost. > >> > > > >Uhm, I'm not sure I completely understand what you mean but iterating > >once (!) over an array of 5 to 50 PeerNode objects and calling a method > >that simply returns an int (which most probably gets inlined anyway) is > >something I do consider "near zero CPU cost." > > > Whereas asking a Hashmap it's size probably doesn't iterate over an > array as it probably tracks it's size with a variable. While iterating > over the peers list is not a big deal for the /darknet/ page, it may > matter if knowing the number of connected peers is useful in one or more > of the pieces of the node's code that may run tens of times a second or > more. > >The problem with node.getPeerNodeStatusSize() is that state information > >for a PeerNode can change during the point getPeerNodeStatusSize() is > >called and the PeerNode's status itself is shown on the page. To fix > >that you'd either have to synchronized Node externally (which is a > >_very_ bad idea) or you'd have to return a list of shallow PeerNode > >copies that don't change their state after returning them. > > > The thing you state as being a problem isn't really a problem in my > mind, though it seems you were fixing a different thing than I thought > you were fixing. On the other hand, iterating the list of PeerNodes, > locking each one, grabbing the information you need, unlocking it and > counting the statuses is the only way to fix the consistency issue you > talk about. Your code does not, for example, fix the case where a > PeerNode goes into or out of routing backoff and the status displayed > disagrees. I personally took the approach that that whole class of > conditions was not important when it only matters for us silly humans, > who can reload a page anyway. > > What does nag me is, for example, peers that, on the /darknet/ page, > have a status of disconnected but are clearly connected when looking at > the other fields in the table, yet nothing changes on repeated page > loads (i.e. the status updating code is broken somewhere that hasn't > been found in the several times I've looked). I think this nagging > issue is a much bigger deal than the changes your made to the code, > which, in my experience happened no more than every hundred page loads. > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl >
-- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20060801/56247f78/attachment.pgp>
