Re: 8206145 : dbgsysSocketClose - do not restart close if errno is EINTR [linux] - was : RE: RFR : 8205959 : Do not restart close if errno is EINTR

On 3/07/2018 1:41 AM, Thomas Stüfe wrote: Hi Alan, Whether to repeat close() in case of EINTR seems to differ between platforms. POSIX leaves it open: "If close() is interrupted by a signal that is to be caught, it shall return -1 with errno set to [EINTR] and the state of fildes is

Re: RFR : 8205959 : Do not restart close if errno is EINTR

I think because the only two possible outcomes are either that the FD was not dup'd, in which case things carry on as before, or that it was dup'd, in which case (at least in the JVM) re-dupping won't really do anything harmful since the target FD already references the dead socket FD. The POSIX

Re: Review Request JDK-8200559: Java agents doing instrumentation need a means to define auxiliary classes

My proposal of ClassDefiner API allows the java agent to define auxiliary classes in the same runtime package of the class being instrumented. You raised other use cases that are not addressed by this proposal. As Alan replied, the ability to define any arbitrary class would be an attractive

Re: 8206145 : dbgsysSocketClose - do not restart close if errno is EINTR [linux] - was : RE: RFR : 8205959 : Do not restart close if errno is EINTR

On 02/07/2018 16:41, Thomas Stüfe wrote: Hi Alan, Whether to repeat close() in case of EINTR seems to differ between platforms. POSIX leaves it open: "If close() is interrupted by a signal that is to be caught, it shall return -1 with errno set to [EINTR] and the state of fildes is

Re: 8206145 : dbgsysSocketClose - do not restart close if errno is EINTR [linux] - was : RE: RFR : 8205959 : Do not restart close if errno is EINTR

Hi Alan, Whether to repeat close() in case of EINTR seems to differ between platforms. POSIX leaves it open: "If close() is interrupted by a signal that is to be caught, it shall return -1 with errno set to [EINTR] and the state of fildes is unspecified." Linux recommends *not* repeating the

Re: 8206145 : dbgsysSocketClose - do not restart close if errno is EINTR [linux] - was : RE: RFR : 8205959 : Do not restart close if errno is EINTR

On 02/07/2018 14:44, Baesken, Matthias wrote: I created a bug and a webrev , please review . https://bugs.openjdk.java.net/browse/JDK-8206145 http://cr.openjdk.java.net/~mbaesken/webrevs/8206145/ Why is this Linux only? I assume the do-while should be removed completely. -Alan.

8206145 : dbgsysSocketClose - do not restart close if errno is EINTR [linux] - was : RE: RFR : 8205959 : Do not restart close if errno is EINTR

I created a bug and a webrev , please review . https://bugs.openjdk.java.net/browse/JDK-8206145 http://cr.openjdk.java.net/~mbaesken/webrevs/8206145/ ( The other bug where a similar issue was addressed is https://bugs.openjdk.java.net/browse/JDK-8205959 ) Best regards, Matthias >

Re: RFR : 8205959 : Do not restart close if errno is EINTR

In reference to 8205959, where is it stated that dup2 is any more restartable than close ?? AFAICS both leave things undefined/unspecified if they set EINTR. David On 2/07/2018 7:03 PM, Langer, Christoph wrote: Hi Matthias, forwarding to serviceability-dev, because debugging is usually

Re: RFR : 8205959 : Do not restart close if errno is EINTR

+1. Please fix this for Linux! Thanks. On Mon, Jul 2, 2018 at 11:03 AM, Langer, Christoph wrote: > Hi Matthias, > > forwarding to serviceability-dev, because debugging is usually discussed > there. > > Yes, I would think this coding should be fixed, too. Can you open a bug and > prepare a

Re: Review Request JDK-8200559: Java agents doing instrumentation need a means to define auxiliary classes

On 02/07/2018 09:41, Rafael Winterhalter wrote: Hi, I was wondering if a solution for this problem is still planned for JDK 11 giving the beginning ramp down. With removing sun.misc.Unsafe::defineClass, Java agents only have an option to use jdk.internal.misc.Unsafe::defineClass for the

RE: RFR : 8205959 : Do not restart close if errno is EINTR

Hi Matthias, forwarding to serviceability-dev, because debugging is usually discussed there. Yes, I would think this coding should be fixed, too. Can you open a bug and prepare a change? Thanks Christoph > -Original Message- > From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On

Re: Review Request JDK-8200559: Java agents doing instrumentation need a means to define auxiliary classes

Hi, I was wondering if a solution for this problem is still planned for JDK 11 giving the beginning ramp down. With removing sun.misc.Unsafe::defineClass, Java agents only have an option to use jdk.internal.misc.Unsafe::defineClass for the use-cases that I described. I think it would be a