[Bug testsuite/66005] libgomp make check time is excessive

["tschwinge at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66005

Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|FIXED                       |---
             Status|RESOLVED                    |REOPENED

--- Comment #10 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #8)
> > --- Comment #7 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
> > Resolved for GCC 14.  Not planning on backporting to release branches (but
> > could, if desired).
> 
> Unfortunately not: flock is completely unportable.  It's not in
> POSIX.1/XPG7, and none of Solaris, macOS, or AIX have it.

OK, indeed my approach depends on 'flock'.  Otherwise, we still serialize
'check-target-libgomp', as before.

(In reply to Jakub Jelinek from comment #9)
> r5-3553 uses if {![catch {open $path {RDWR CREAT EXCL} 0600} fd]} { to
> determine which make check invocation should be given a particular batch of
> tests (in an initially empty directory), could you use that instead?

We'd like something that blocks until the lock is available, and something that
works on file descriptors and unlocks implicitly upon 'close'/process exit (to
avoid stale locks).

Using something like Jakub posted with spinning probably does waste too many
parallel slots here?  I'll try to experiment with that, though: at the long
tail at the end of overall parallel testing (that is, when all parallel slots
are otherwise unused), it's still better than no parallelism at all?

Could we easily build a portable 'flock'-like using 'fcntl' locking primitives?
 (I've not yet looked.)