RFR 8237858: PlainSocketImpl.socketAccept() handles EINTR incorrectly

[Vyom Tiwari]

Hi Daniel/Michael,

Please find the latest webrev(
http://cr.openjdk.java.net/~vtewari/8237858/webrev0.2/index.html), where i
put a test case as well.
Thanks,
Vyom

On Wed, Mar 11, 2020 at 3:16 PM Bernd Eckenfels <ecki at zusammenkunft.net>
wrote:

> 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-bounces at openjdk.java.net> im Auftrag von Alan
> Bateman <Alan.Bateman at oracle.com>
> *Gesendet:* Wednesday, March 11, 2020 9:21:24 AM
> *An:* Vyom Tewari26 <vtewar26 at in.ibm.com>
> *Cc:* net-dev at openjdk.java.net <net-dev at 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.
>


-- 
Thanks,
Vyom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200317/5ac1a80e/attachment-0001.htm>