Hello, Depending on the test environment you don't need much native tools. You can use java.io.File to open /proc/thread-self to get the TID and use ProcessBuilder to execute the kill command.
Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: net-dev <net-dev-boun...@openjdk.java.net> im Auftrag von Alan Bateman <alan.bate...@oracle.com> Gesendet: Wednesday, March 11, 2020 9:21:24 AM An: Vyom Tewari26 <vtewa...@in.ibm.com> Cc: net-dev@openjdk.java.net <net-dev@openjdk.java.net> Betreff: Re: RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR incorrectly 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.
