On 29/04/2019 17:47, Michael McMahon wrote:
:
It still ends up as a close of the socket's file descriptor at the OS
level
one way or the other. Closing a socket's InputStream or OutputStream
never resulted in a shutdown() call to the OS. If you want socket
shutdown
then you need to call shutd
On 29/04/2019, 12:17, Alan Bateman wrote:
On 29/04/2019 10:52, Michael McMahon wrote:
Hi,
This is another change which is part of the general cleanup of
SocketImpls.
The change removes support for pre JDK 1.4 socketimpls which do not
implement
the timed connect method. These SocketImpls ha
On 29/04/2019, 17:35, David Lloyd wrote:
On Mon, Apr 29, 2019 at 10:54 AM Michael McMahon
wrote:
On 29/04/2019, 13:08, Chris Hegarty wrote:
On 29/04/2019 12:17, Alan Bateman wrote:
...
Changing SIS.close and SOS.close to caller super.close raises a
number of questions. These close shoul
On Mon, Apr 29, 2019 at 10:54 AM Michael McMahon
wrote:
>
>
>
> On 29/04/2019, 13:08, Chris Hegarty wrote:
> >
> > On 29/04/2019 12:17, Alan Bateman wrote:
> >> ...
> >> Changing SIS.close and SOS.close to caller super.close raises a
> >> number of questions. These close should never be called
> >
On 29/04/2019, 13:08, Chris Hegarty wrote:
On 29/04/2019 12:17, Alan Bateman wrote:
...
Changing SIS.close and SOS.close to caller super.close raises a
number of questions. These close should never be called
Socket.getInputStream and getOutputStream don't leak these streams to
user code (
On 29/04/2019 13:24, Alan Bateman wrote:
433 protected synchronized void bind(InetAddress address, int lport)
[...]
which for me justifies that it should be volatile.
I think you are might be mixing up the lock on the vs. fdLock. From what
I can tell, isBound is only accessed by doConnect
On 29/04/2019 13:00, Daniel Fuchs wrote:
Hi Alan,
On 29/04/2019 12:17, Alan Bateman wrote:
I don't think AbstractPlainSocketImpl.isBound needs to be volatile as
it is guarded by the synchronization on the impl (the doConnect and
bind methods are synchronized).
I see that it is set outside of
On 29/04/2019 12:17, Alan Bateman wrote:
...
Changing SIS.close and SOS.close to caller super.close raises a number
of questions. These close should never be called Socket.getInputStream
and getOutputStream don't leak these streams to user code (they used to
but now in JDK 13). My concern is
Hi Alan,
On 29/04/2019 12:17, Alan Bateman wrote:
I don't think AbstractPlainSocketImpl.isBound needs to be volatile as it
is guarded by the synchronization on the impl (the doConnect and bind
methods are synchronized).
I see that it is set outside of any synchronized block
in AbstractPlainSo
On 29/04/2019 10:52, Michael McMahon wrote:
Hi,
This is another change which is part of the general cleanup of
SocketImpls.
The change removes support for pre JDK 1.4 socketimpls which do not
implement
the timed connect method. These SocketImpls have not been compilable
since 1.4 and limited
Hi Daniel,
On 29/04/2019, 11:34, Daniel Fuchs wrote:
Hi Michael,
I'm too new to networking libs to actually review
this change. However I have eyeballed it and it looks
like a very nice simplification and cleanup!
I didn't see anything that looked wrong.
Two thing though:
java/net/Socket.java
Thanks Chris. Comments noted.
- Michael
On 29/04/2019, 11:26, Chris Hegarty wrote:
Michael,
On 29/04/2019 10:52, Michael McMahon wrote:
Hi,
This is another change which is part of the general cleanup of
SocketImpls.
The change removes support for pre JDK 1.4 socketimpls which do not
implem
Hi Michael,
I'm too new to networking libs to actually review
this change. However I have eyeballed it and it looks
like a very nice simplification and cleanup!
I didn't see anything that looked wrong.
Two thing though:
java/net/Socket.java: (and at multiple other places in this file)
1615
Michael,
On 29/04/2019 10:52, Michael McMahon wrote:
Hi,
This is another change which is part of the general cleanup of SocketImpls.
The change removes support for pre JDK 1.4 socketimpls which do not
implement
the timed connect method. These SocketImpls have not been compilable
since 1.4 and
Hi,
This is another change which is part of the general cleanup of SocketImpls.
The change removes support for pre JDK 1.4 socketimpls which do not
implement
the timed connect method. These SocketImpls have not been compilable
since 1.4 and limited runtime support has been provided since then,
Thanks Alan!
I have already pushed those changes - but I'll retain this trick
for the next batch. FWIW I saw that the default value for the
backlog in the impl was 50, so that's what I'd been using.
But not having to specify it at all is indeed a better solution.
best regards,
-- daniel
On 27/
16 matches
Mail list logo
