I agree, I wasn't aware of the other uses of ::socket in the libnet codebase.
Thus, I've added a new common function, NET_SocketOpen that can be used by all
the source files in libnet and revised my patch:
diff -r 95c0644a1c47 src/java.base/unix/native/libnet/Inet4AddressImpl.c
--- a/src/java.b
+1 I think this makes a lot of sense
> On 10. Jul 2018, at 17:54, Alan Bateman wrote:
>
> On 10/07/2018 17:40, Martin Buchholz wrote:
>> I agree with this approach - it parallels the efforts made with O_CLOEXEC in
>> past years.
>>
>> According to
>> https://www.freebsd.org/cgi/man.cgi?query
On 10/07/2018 17:40, Martin Buchholz wrote:
I agree with this approach - it parallels the efforts made with
O_CLOEXEC in past years.
According to
https://www.freebsd.org/cgi/man.cgi?query=socket&sektion=2
SOCK_CLOEXEC is also available on freebsd.
This is something that doesn't come up too oft
Hi all,
I just tried to run netty[1] testsuite with the latest jdk11 EA release (21)
and saw some class-cast-exception with our custom SSLEngine implementation
Caused by: java.lang.ClassCastException: class
io.netty.handler.ssl.OpenSslEngine cannot be cast to class
sun.security.ssl.SSLEngineI
I agree with this approach - it parallels the efforts made with O_CLOEXEC
in past years.
According to
https://www.freebsd.org/cgi/man.cgi?query=socket&sektion=2
SOCK_CLOEXEC is also available on freebsd.
On Tue, Jul 10, 2018 at 1:36 AM, Andrew Luo <
andrewluotechnolog...@outlook.com> wrote:
> Hi
Hi,
I want to propose to use SOCK_CLOEXEC when opening sockets in the OpenJDK. I
ran into some issues when forking processes (in JNI/C/C++/native code) on Linux
where OpenJDK had opened a socket (in Java code). The child process ends up
inheriting a file descriptor to the same socket, which i
