The test passes. But as far as the race goes that may be a fluke. I'll
add the sleep to be on the safe side. Thanks Martin,
-Rob
On 12/10/12 23:20, Martin Buchholz wrote:
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 <[email protected]
<mailto:[email protected]>> 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/
<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)
