Hi Eric, * Eric Blake wrote on Mon, Apr 20, 2009 at 06:44:17PM CEST: > Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> writes: > > > You can try this; test against git next of Automake. > > However, it also causes a hang on Cygwin, so there may be an independent > > bug (in the test or in perl); the lock() called from the thread seems to > > never complete. > > Hmm. On some systems flock(2) is documented as being per-process only (that > is, you can't lock a file from yourself in a multi-threaded app[1]).
Oh. I didn't know that. My test was a rather quick hack anyway, good to have a good reason now not to commit it. > I'm not > sure if flockfile(3) (at the FILE*) level, or fcntl(2)/lockf() at the fd > level, > do any better, but that doesn't matter since perl's flock states that whether > it was implemented with flock or fcntl depends on how perl was configured. It doesn't really matter: nothing within Automake requires file locking at the perl threads level. Well, it may matter for the implementation issues that the Cygwin developers work on. > Therefore, is this test even valid, since you did it via perl threads as > opposed to independent processes? Likely not. > But the point remains that we DO want perl's > flock to work for cross-process locking (automake and autoconf both need a > lock > on autom4te.cache/requests, to block whichever task starts late). Yes, definitely. And a testsuite addition to Autoconf or Automake to ensure this would be good, I guess. Thanks for doing the research! Cheers, Ralf
