Looking for a sponsor to review changes made to two unit tests under jdk/test
sadhak001 at gmail.com
Mon Apr 8 23:41:44 UTC 2013
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?
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
> 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
*JUG activity:* LJC Advocate (@adoptopenjdk & @adoptajsr programs)
*Devoxx UK 2013 was a grand success:*
*Don't chase success, rather aim for "Excellence", and success will come
chasing after you!*
More information about the core-libs-dev