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/
<http://cr.openjdk.java.net/%7Erobm/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
<[email protected] <mailto:[email protected]>> 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)
