On 11/03/2020 08:09, Vyom Tewari26 wrote:
Hi Alan,
Thanks for comment yes for >=JDK13 we are using new socket impl which
does not have this problem, i am not planning to wright a test, to
test this issue we need to get the native thread ID then we have to
interrupt the thread to see if JDK code is behaving as expected.
I tested this issue at my local Linux env, what i did is modify the
java.lang.Thread.getId() to always return the *native thread id of
main thread* and use this native thread id in the test program to send
a signal(kill -SIGPIPE threadid) and i checked that JDK code is
behaving as expected.
We can try to write a test case(which requires some native code as
well) which simulate the above but that will be lot of work.
We can file a new issue to write a test which test
how(read,write,accept) operations behave when they are interrupted by
a signal.
Alan, what do you think ?.
Native tests used to be hard but there is supporting infrastructure in
the build for some time that makes it a lot easier. In this case, I
think it should be possible to invoke a JNI method that returns the
native thread id and then it can be signalled when the thread is blocked
in accept (or read or write). So it shouldn't be too hard, it comes to
whether anyone has time.
-Alan.
