Hi Alan,Daniel, Please find the latest webrev( http://cr.openjdk.java.net/~vtewari/8237858/webrev0.7/index.html). I have added a new native method and removed the hardcoding(SIGPIPE).
I gave a thought on creating a separate thread and sending a signal but it will further increase the complexity of the test. If tests send signals in separate threads then tests have to make sure that server thread is alive and running. Thanks, Vyom On Sat, Jun 27, 2020 at 12:56 PM Vyom Tiwari <vyomm...@gmail.com> wrote: > Hi Alan, > > Thanks for the review comment, we can send multiple signals for sure. I > will create a thread which will send multiple signals. > > Creating a new native method that returns a signal is a bit too much as > SIGPIPE is a standard signal, but I will add a native method as you > suggested. > > I think webrev is ignoring the spaces that is why you are observing the > formatting issues in (linux/bsd)_close.c files. In my local repo code looks > well formatted. > > Thanks, > Vyom > > On Sat, Jun 27, 2020 at 11:46 AM Alan Bateman <alan.bate...@oracle.com> > wrote: > >> On 26/06/2020 05:17, Vyom Tiwari wrote: >> > Hi Daniel/Alan, >> > Please find the latest >> > webrev(http://cr.openjdk.java.net/~vtewari/8237858/webrev0.6/index.html >> ). >> > >> I think we can do better than one signal after 200ms. Have you given any >> thought to have a thread that signals many times so that you have a >> better chance of tickling bugs? One other comment at this time is that >> the value of SIGPIPE is still hardcoded - I think you'll need to add >> another native method to return its value. >> >> BTW: The formatting issues with linux_close.c and bsd_close.c are the >> same as the previous iterations. Did you track down that issue, I think >> you thought it was webrev or an issue with your patch queue. >> >> -Alan. >> >> > > -- > Thanks, > Vyom > -- Thanks, Vyom
