CR 6860309 - solaris timing issue on thread startup

Alan Bateman Alan.Bateman at
Mon Nov 14 08:05:26 UTC 2011

On 14/11/2011 00:42, David Holmes wrote:
> Will the exec'd process block until the copier threads read from its 
> output streams? If not then the copier threads (well stdin anyway) 
> could read their input and have terminated before the main thread even 
> reaches the original sleep() call.
> I don't think this test can be written correctly as-is. Even using a 
> CountDownLatch won't help because you have to sync with two copier 
> threads, so the first could be finished before the second signals the 
> latch.
> I would think we would need to exec our own process (a Java one of 
> course) that assists with the synchronization issue - ie by not 
> terminating until it receives an input token. At least that way we 
> know the copier threads can not proceed passed the read() calls, even 
> if we can't be 100% certain they are in the read at the time the 
> process is destroyed.
The test runs cat without any arguments so the Copier threads will block 
when they read from the stream. If we can get the main thread to wait 
until the Copier threads are just about to do the read, sleep for a bit, 
then the threads should be blocked in the read when we destroy the 
process. It's not ideal but I don't think there is any other way to test 


More information about the core-libs-dev mailing list