On 21/01/16 17:45, Mark Sheppard wrote:
Thanks Sean
i can revert the isClosed(), I put them in to make the access consistent
I'd question if the synchronized isClosed() and setClosed(boolean)
helper methods are needed at all. The volatile closed boolean variable
should be enough to manage this state flag. Either way, I don't think
the synchronization around the closed variable is root cause of this
issue and performance issues could be addressed in another change if
necessary (playing safe)
regards,
Sean.
regards
Mark
On 20/01/2016 18:17, Seán Coffey wrote:
Hi Mark,
SelectorImpl.java:
line 125, could you use a 2 arg method call to dprint. It'll print
the stacktrace instead :
dprint(".close: selector.close: " + t); --> dprint(".close:
selector.close", t);
The "while (!isClosed()) " change introduces a new hot lock on closed
variable. Hopefully, it won't impact performance too much.
Looks good to me otherwise.
Regards,
Sean.
On 20/01/16 16:16, Mark Sheppard wrote:
Hi,
an update has been made to the webrev
http://cr.openjdk.java.net/~msheppar/8144144/webrev.03/
an anomaly was found in the select loop of the SelectorImpl.run()
method
some defensive programming, for selector null references, have been
added, also.
regards
Mark
On 08/01/2016 17:49, Mark Sheppard wrote:
Hi
please oblige and review the following changes
http://cr.openjdk.java.net/~msheppar/8144144/webrev/
which addresses the issue
https://bugs.openjdk.java.net/browse/JDK-8144144
the changes ensure that an Acceptor and its associated
ServerSocket/ServerSocketChannel
are closed.
regards
Mark
