Thanks, Rob. I'm OK with your webrev.02, and I'm OK with putting back a 10ms sleep, if you want to also do that. I'm not sure what happens on macosx or windows - you might want to think about that.
Martin On Fri, Oct 12, 2012 at 1:18 PM, Rob McKenna <rob.mcke...@oracle.com> wrote: > Sorry for not responding sooner, I was out for the evening. > > I threw this fix into our test infrastructure (jprt) before I left though, > and I see it has passed. > > http://cr.openjdk.java.net/~robm/8000817/webrev.02/ > > I'm a little unclear as to why you'd prefer to throw that away, can you > elaborate? > > As ugly as a Thread.sleep(10) is, it hasn't historically been a problem on > platforms other than Solaris. Perhaps this in combination with the stack > hackery? > > Let me know either way and I'll get it integrated sharpish! Thanks, > > -Rob > > > > On 12/10/12 19:54, Martin Buchholz wrote: > > > > On Fri, Oct 12, 2012 at 11:47 AM, Alan Bateman <alan.bate...@oracle.com>wrote: > >> >> Checking for readBytes should be better but it might still be fragile >> because there isn't any guarantee that the thread is in the read syscall >> (although the window should be a lot smaller). Although none of us like >> using sleep, this may be a case where we need a short sleep to improve our >> chances. >> >> > Yup. > > Sure would be nice if we could see native methods in the stacktraces, > kind of like this: > > java.lang.Thread.State: RUNNABLE > at (C/C++) __kernel_vsyscall( ()) > at (C/C++) readBytes( (jre/lib/i386/libjava.so)) > at (C/C++) Java_java_io_FileInputStream_readBytes( > (jre/lib/i386/libjava.so)) > at java.io.FileInputStream.readBytes(Native Method) > > >
