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?)
currentSet is sel.selectedKeys() and its a big NO to use add() on this. The current JRE appears to (its a black box) let it pass without problem. It's behaviour defined by the spec. is to throw UnsupportedOperationException, but there's a bug in the implementation, may not be so lucky with others.
Other comments
--------------
A workaround: First type is when there is a bug in an implementation; write code that takes steps to make it work as intended. Second type is when something doesn't work as you would like; write code to do what you want. In neither case should you break the spec., unless it's targeted at a particular implementation.
Disallowed: Ideally implementations would not compile disallowed code but its too hard sometimes.
Undefined behaviour: If it isn't defined anything could happen, so avoid depending on a particular implementation. (There may be limits in cases)
e.g. With several waiting threads, Another [T1] calls notify(), it's undefined which will will wake but defined that only one will. If there is also another thread [T2] contending for the lock, when T1 releases it's undefined whether T2 or the awoken thread gets the lock first.
Unsynchronised multi-threaded (r/w) access to objects data (including arrays, long, double) is disallowed (I hope) but implementation can't detect this. So if you try, anything could happen including crashing the JVM.
You may think that if it was guaranteed (somehow) an object could *never* be accessed (& finish everything it needs) simultaneously by any two threads then *no* synchronisation would be needed. You would be wrong. I'll let someone else tell you why.
I'd love to see a workaround or fix for writeSelectionScrewed.
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
