RFR: 8000817: Reinstate accidentally removed sleep() from ProcessBuilder/Basic.java
Martin Buchholz
martinrb at google.com
Fri Oct 12 22:20:53 UTC 2012
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.mckenna at 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.Bateman at 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)
>
>
>
More information about the core-libs-dev
mailing list