Great work on QThreadFactory, I hadn't yet relized the problem of thread
overestimates...

Also, why the heck didn't I think to separate the numLock incriment from
the thread creation *smacks self*, that should eliminate EVERY case of a
lock being held for a thread creation or deletion, great!  

I have a report on IRC of these latest changes with moving
KillSurplusConnections to a thread allowing connection overload, we need
to look at that, I'm having a thread dump transmitted to me via freenet,
and I will share it on this ML to preserve the reporter's anonymity.

--Brandon

On Fri, 09/26/03 at 09:39:39 -0400, Edward J. Huff wrote:
> On Fri, 2003-09-26 at 08:52, Niklas Bergh wrote:
> > Should be fixed now. It might be a good idea if the one who has written
> > the code had a little look.
> 
> I'm looking now, I'm sure Brandon will also look at it.  I wondered
> about which monitor was going to be signaled there....
> 
> On Fri, 2003-09-26 at 05:33, Edward J. Huff wrote: 
> > On Fri, 2003-09-26 at 05:17, Edward J. Huff wrote:
> > 
> > > I claim it is helpful.  The QThreadFactory locking reduces contention
> > > for locks.  It has a bug or two, which I have fixed.
> > > 
> > > Problem with killsurplusconnections was that while one thread is
> > > killing a connection, the others wait.  And none of them gets out
> > > of OCM.put() until lru.size() <= maxconnections.
> > > 
> > 
> > I've build this and am testing it.  It runs compute bound, will
> > look at why tomorrow.  Sources are committed, 6208.
> 
> Sorry about that.  I saw that my node could fetch the help index,
> and went ahead and committed, without noticing the errors on
> stdout.  My log file was 85 meg this morning...
> 
> > (BTW I assume this won't become freenet-unstable-latest.jar...
> > will it?)
> 
> I guess that's why they call it "unstable..."  And now I see why
> there are sometimes two or more different versions of one build...
> 
> No, I just downloaded unstable-latest, and it is build 6207.
> I see that Ed Tomlinson said he built it from CVS source.
> 
> -- Ed Huff
> 
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED] 
> > > [mailto:[EMAIL PROTECTED] On Behalf Of Ed Tomlinson
> > > Sent: den 26 september 2003 13:03
> > > To: Brandon Low
> > > Cc: [EMAIL PROTECTED]
> > > Subject: Re: [freenet-dev] [PATCH] [JAR] More locking fixes (BIG ONE)
> > > 
> > > 
> > > Hi,
> > > 
> > > Looks like something is not quite right in 6208.  I am seeing 
> > > _lots_ of 
> > > these errors (several per minute):
> > > 
> > > Sep 26, 2003 7:40:41 AM (freenet.Ticker, Ticker, ERROR):
> 
> Needs to print the time zone...  So does the mailer above...
> 
> > [...]
> > > 
> > > The class getting the exception changes...
> > > 
> > > sorry about the spacing - info should all be there though.    
> > > Built from cvs.
> 
> Ok, so commits don't automatically get into unstable-latest...
> 
> > > using debian unstable and sun java 1.4.2-b28
> > > 
> > > Hope this helps
> > > Ed Tomlinson
> > > 
> > > On September 25, 2003 07:24 pm, Brandon Low wrote:
> > > > Ok, I think I've nailed down all of the remaining locking 
> > > issues which 
> > > > were plaguing my node.  Last time I dumped threads there was only 1 
> > > > out of over 200 that was waiting for a monitor.  This is a pretty 
> > > > extreme patch, as it moves KillSurplusConnections to a 
> > > daemon thread, 
> > > > and completely redoes the locking in QThreadFactory, but on 
> > > my node it 
> > > > works, and has brought new levels of peak BW performance, 
> > > and a very 
> > > > smoothe running node.
> > > >
> > > > http://lostlogicx.com/transfer/freenet-locking-improvements.6207.jar
> > > > 
> > > http://lostlogicx.com/transfer/freenet->
> > locking-improvements.6207.patch
> > > >
> > > > --Brandon
> -- 
> Edward J. Huff <[EMAIL PROTECTED]>



> _______________________________________________
> Devl mailing list
> [EMAIL PROTECTED]
> http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to