On Mon, Oct 13, 2003 at 04:26:58PM +0100, Toad wrote:
> On Mon, Oct 13, 2003 at 04:06:56PM +0100, Toad wrote:
> > On Sun, Oct 12, 2003 at 12:54:12AM +0100, Jonathan Howard wrote:
> > > I'm noticing not all messages are getting to my e-mail, I should change
> > > provider but I like free.
> > >
> > > Niklas Bergh wrote:
> > > >Great!
> > > >
> > > >But.. could you elaborate on the exact nature of the bug and what the
> > > >changes to WSL-select was?
> > >
> > > RSL: removes selected key first time. Nothing major if it isn't, just
> > > gets recorded by readinessSelectionScrewed. I haven't seen anything else
> > > setting readinessSelectionScrewed but maybe others do.
> > >
> > > Adding writeSelectionScrewed because I got sick of seeing my own output
> > > on my console but want to see it recorded. (I now show the io messages)
> > >
> > > Remove dead code and from WSL remove;
> > > protected final void fixKeys() {
> > > //this never adds anything
> > > Iterator i = sel.keys().iterator();
> > > while (i.hasNext()) {
> > > SelectionKey current = (SelectionKey) i.next();
> > > if (current.isValid() && current.isWritable()
> > > && (!currentSet.contains(current)))
> > > Core.logger.log(this, "fixKeys added "+current,
> > > Logger.NORMAL);
> > > currentSet.add(current);
> > > }
> > > }
> > >
> > > This is circumventing selection process.
> > > It logs when keys have just become writable but not in-time for select()
> > > to get them this time around.
> > > Then add all keys to the currentSet. Making non-writable keys available
> > > for processing. (WHY?)
> >
> > PLEASE COME BACK WHEN YOU HAVE WRITTEN AND DEBUGGED A SIGNIFICANT
> > MULTI-PLATFORM PROGRAM USING JAVA.NIO.
>
> Sorry, what I meant was: don't write off fixKeys just because it doesn't
> make sense according to your reading of the spec. The JVMs are buggy.
> Very very buggy, w.r.t. NIO. Anyone trying to write a serious
> cross-platform server in java needs his head examined. Anyway, if we
> don't use fixKeys, we can remove it - but if we do use it, it's because
> selection was breaking.One theory we had was that it was because we didn't always completely drain the read-selected or write-selected channels, so they didn't end up on the selector on the next iteration despite still being readable/writable. We tried to just add those connections to currentSet but it didn't work. The reason we don't always use all available bytes is bandwidth limiting, a horrible monster that you may want to have a look at (ThrottledSelectorLoop). -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so.
signature.asc
Description: Digital signature
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
