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