Nice to see this, hope it works out. Ismael
On Fri, Jan 25, 2019, 6:11 AM Alan Bateman <alan.bate...@oracle.com wrote: > > I've created a branch in the sandbox, named "niosocketimpl-branch", with > a prototype SocketImpl implementation based on the infrastructure in > sun.nio.ch package that supports the NIO channel implementations. The > branch also includes the changes to java.net.Socket and ServerSocket to > use this SocketImpl by default. > > There are several motivations for this prototype: The existing > PlainSocketImpl is not fit for purpose in the potential future world of > fibers that park instead of blocking carrier threads in syscalls. As I'm > sure most people are on net-dev are aware, PlainSocketImpl is horrible > to maintain due to the complexity of the code paths in its native > methods. Replacing PlainSocketImpl, along with its associates > SocketInputStream and SocketOutputStream, bring other benefits such as > not needing to use the thread stack for I/O and not needing the fd table > data structure to support asynchronous close. > > We have to be a cautious about replacing the PlainSocket/SIS/SOS after > 20 years of service. It is likely that there is behavior in unspecified > areas and corner case scenarios that existing applications or libraries > may depend upon. There is performance work to do but it's possible there > are cases where the performance might degrade, e.g. many years ago there > were attempts to fix a synchronization issue in PlainSocketImpl that > lead to complaints from usages involving hundreds of threads blocking on > ServerSocket::accept. To that end, we are planning to evolve the > prototype to allow the old and new SocketImpls to co-exist, maybe > switched by a system property or some other means. Going there may > require a bit yak shaving, for example in the SOCKS and HTTP proxy > implementations as they need to be re-worked to forward rather than > sub-class. If the prototype goes further then the idea is that both > implementations could be included in the JDK for a few releases before > removing the old code. > > The prototype doesn't have a replacement for PlainDagramSocketImpl at > this time. There are a few issues around how legacy MulticastSocket > behaves that will take a bit of time to sort out. Ideally its > replacement will use the same infrastructure as the DatgramChannel > implementation as that supports modern muilticasting features and is a > lot easier to maintain. > > For now, we (= Michael McMahon and myself for now) will iterate on this > prototype in the sandbox. If we go forward with it then we'll likely > create a JEP. > > -Alan >
