Re: [patch] testsuite: Fix a racy FAIL on gdb.base/multi-forks.exp

[Joel Brobecker <brobecker@adacore.com>]

I am not very familiar with this testcase, so please consider this
as an informal review. I started looking at this just because I was
actually wondering about the availability of "close"....

> Instead of the output suppression by `close (1)' some sleep would also fix it
> if close (1) is not compatible enough.

As far as I can tell, "close" is POSIX, so should be fairly portable.
I'm not entirely sure about Windows, but I do think it's available.
The symbol name might be _close, though.

That being said, I see later in the same testcase that this problem
is already handled a different way. Basically, we know that the
inferiors are going to print a bunch of traces, so we just wait
for all of them to be printed before we do the next test:

    # The output from the child processes can be interleaved arbitrarily
    # with the output from GDB and the parent process.  If we don't
    # consume it all now, it can confuse later interactions.
    set seen_done 0
    set seen_break 0
    set seen_prompt 0
    set seen_timeout 0
    while { ($seen_done < 16 || ! $seen_prompt) && ! $seen_timeout } {
        # We don't know what order the interesting things will arrive in.
        # Using a pattern of the form 'x|y|z' instead of -re x ... -re y
        # ... -re z ensures that expect always chooses the match that
        # occurs leftmost in the input, and not the pattern appearing
        # first in the script that occurs anywhere in the input, so that
        # we don't skip anything.
        gdb_expect {
            -re "($decimal done)|(Breakpoint)|($gdb_prompt)" {
                if {[info exists expect_out(1,string)]} {
                    incr seen_done
                } elseif {[info exists expect_out(2,string)]} {
                    set seen_break 1
                } elseif {[info exists expect_out(3,string)]} {
                    set seen_prompt 1
                }
                array unset expect_out
            }
            timeout { set seen_timeout 1 }
        }
    }

Would it make sense to do the same in the case where we follow
the child?

On a side note, I try to avoid delays such as "sleep" like the plague.
A one or two second delay on its own is not that bad, but they tend
to add-up pretty quickly. Since our testsuite is sequential, it's time
wasted doing nothing. So I only use them if I don't have any other choice.

-- 
Joel