On Mon, Sep 15, 2003 at 01:52:17AM +0100, Jonathan Howard wrote:
> I'm new to looking into the Freenet code and haven't got the full 
> picture of workflow, but I know it isn't pleasant.
> The good news is I'm running with Windows ME MaxConnections set to 256 
> and freenet's max connections up to 128 without any additional bugs.

I assume you are using the current version, 6193? Anonymous CVS is
pretty old. Get the current unstable source tarball from
http://freenetproject.org/snapshots/
> 
> The squeamish should close their eyes now.
> 
> I've been trying out a profiler, seeing what it would pick up. It was 
> counting waits so lead me to the following code.
> 
> BlockingQueue (the tabs are messed up in my changed version)
> Half a dozen bugs and the potential to crash Java. You can't go blaming 
> sun for the spec without a suitable alternative, (many have tried). See 

Hrrm? What bugs?

> attached TimeTime.java for one of the unwritten limits of timing capability.

Are you saying the profiler said that System.currentTimeMillis() is
significant? That's a profiler bug IIRC, caused by it being such a short
method.
> 
> Irreversible - Not totally thread safe, but most will get away with it.

Heh. A patch would help!
> 
> Lots of finals all over the place not making the slightest difference to 
> performance.

That is debatable. Final vars will make a difference; final functions
will make a difference (the difference between virtual and nonvirtual
functions in C++); final classes may or may not, it is a controversial
issue.
> 
> Not fully following the next code I may not be correct, but here's what 
> I see;
> 
> AbstractSelectorLoop register/unregister should be calling sel.wakeup().

Hmm. Wait for zab's reply on that one.
> 
> AbstractSelectorLoop processWaiters that first while loop looks bad.

I don't follow. Maybe zab does.
> 
> WSL/RSL beforeSelect - now why are these calling select?

Ask zab. There was some good reason involving cancelling keys. NIO is a
pig.
> 
> WSL processconnections - currentJob.data - does this need 
> synchronization? From what I can tell using limit is how the bandwidth 
> limit is being set.
> It's only set under one condition though: 
> if(currentJob.data.remaining()>lim)
> Then further down reverted back to it's old value.
> So I have no idea how it's working.
> 

Oh, and don't use assert, throw an InvalidArgumentException.

-- 
Matthew J Toseland - [EMAIL PROTECTED]
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.

Attachment: signature.asc
Description: Digital signature

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

Reply via email to