On Thursday 26 February 2009 20:29:34 Florent Daignière wrote: > * Matthew Toseland <[email protected]> [2009-02-25 17:59:32]: > > > On Wednesday 25 February 2009 10:00:22 Florent Daigniere wrote: > > > Matthew Toseland wrote: > > > > On Tuesday 03 February 2009 11:36:01 [email protected] wrote: > > > >> Author: nextgens > > > >> Date: 2009-02-03 11:36:00 +0000 (Tue, 03 Feb 2009) > > > >> New Revision: 25484 > > > >> > > > >> Modified: > > > >> trunk/freenet/src/freenet/node/NodePinger.java > > > >> Log: > > > >> Improve NodePinger: > > > >> > > > >> -take care of synchronization > > > >> -requeue before we do anything so that we are closer to a 200ms period > > > >> -logging optimizations > > > >> > > > >> @@ -24,35 +37,34 @@ > > > >> run(); > > > >> } > > > >> > > > >> - final Node node; > > > >> - > > > >> public void run() { > > > >> - //freenet.support.OSThread.RealOSThread.logPID(this); > > > >> - try { > > > >> - recalculateMean(node.peers.connectedPeers); > > > >> - } finally { > > > >> - node.ps.queueTimedJob(this, 200); > > > >> - } > > > >> + // Requeue *before* so that it's accurate in any case > > > >> + node.ps.queueTimedJob(this, 200); > > > > > > > > Is this really a good idea? If there is heavy load, you could end up with > > > > hundreds of these jobs running in parallel? > > > > > > > > > > In that case we are screwed anyway; Introduce a "fast-fail" using a > > > volatile boolean if you think it's worth it. > > > > What is the purpose of the 200ms period? > > Good question; that's your code ;) > > I think we use the meanPingTime of connected peers in the load-balancing > algorithm... It does make sense to have "consistent" values. > > I guess that 200ms is just an arbitrarily chosen value.
In which case, why not requeue after running?
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
