Avoiding sleep in V3 testsuite

Mark Mitchell mark@codesourcery.com
Tue Dec 28 01:40:00 GMT 2004


Paolo Carlini wrote:
> Hi,
> 
>> Here's a sketch of how I'm proposing to fix this.  (I'll figure out a
>> better way to define _GLIBCXX_SYSV_SEM.)  Any objections?
>>  
>>
> First blush, certainly not from me.

Great.

>> (Actually, come to think of it, I can't see any reason that we need
>> synchronization at all in this test -- except maybe that we're using
>> "exit" -- rather than "_exit" -- to leave the child, which seems
>> confused in and of itself.  Since this test uses fifos, we can safely
>> assume that _exit exists.  So, I guess to fix 9507.cc, in particular,
>> it would suffice just to remove the sleep calls.)
>>  
>>
> Actually, as probably you already noticed, I'm guilty of adding those sleep
> to that testcase: after the previous commit, changing the openmore, I saw
> intermittent failures on some archs, and tried quickly fixing the problem
> following our usual rough sleep-based strategy... In case you eventually
> decide to only remove completely the sleeps in this case, please make sure
> to regtest on many archs.

Do you have any recollection of which architectures caused the problems? 
  Or a pointer to any previous threads about this issue?  (I have access 
to several different operating systems, but nothing truly exotic.)

I can see one possible problem, in the absence of synchronization.  The 
child will call open on the FIFO; the parent will call open, and then 
seek to the end, due to the use of ios_base::ate.  It is the seek which 
fails, because the FIFO is a pipe.  If the child closes the pipe before 
the seek occurs, perhaps the seek does not fail, or perhaps the parent 
gets stuck.

So, I will leave in the wait/signal calls that I posted; they force the 
parent to do the seek before the child closes the FIFO.  Without the 
sleep calls, the synchronization overhead is very small; microseconds 
instead of seconds.

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304



More information about the Libstdc++ mailing list