Looking for a sponsor to review changes made to two unit tests under jdk/test

[Mani Sarkar]

Is there no better way of waiting rather than using the Thread.sleep(n)
method, I think you will agree that using sleep isn't the most elegant way
to do things.

I did run the patch without sleep, and it executed perfectly well - just
curious about the use of Thread.sleep(n) in general, nothing specific to
this change itself.

When should/can it be used and when not?

Cheers,
mani

On Tue, Apr 9, 2013 at 12:28 AM, David Holmes <david.holmes at oracle.com>wrote:

> On 8/04/2013 9:59 PM, Mani Sarkar wrote:
>
>> Thanks Alan, David for your feedback.
>>
>> So effectively you are saying the Thread.sleep(10) is fine in the test
>> and does not need to be re-written using any of the concurrency library
>> methods.
>>
>
> As I wrote back in one of my earliest emails:
>
> "that aside the latch is not needed. The fork() method starts a thread and
> joins it. So when createNoise() returns we already know for certain that
> the "noise has been created". What the sleep is doing is giving the GC a
> chance to run. "
>
> The sleep has nothing to do with synchronizing with the "noise" thread.
> And synchronization with the "noise" thread is already handled perfectly
> correctly.
>
> David
> -----
>
>
>> --
*Twitter:* @theNeomatrix369
*Blog:* http://neomatrix369.wordpress.com
*JUG activity:* LJC Advocate (@adoptopenjdk & @adoptajsr programs)
*Meet-a-Project:* https://github.com/MutabilityDetector
*Devoxx UK 2013 was a grand success:*
http://www.devoxx.com/display/UK13/Home
*Don't chase success, rather aim for "Excellence", and success will come
chasing after you!*