> > > Well, I've seen strange things happen before. > > > > > > > > Do we think this is safe enough to keep it in 2.1 now the last beta has > > > > been released ? > > > > > > I'd say for Linux it is safe if NFS is not used. For NFS > > > http://stackoverflow.com/questions/575328/fcntl-lockf-which-is-better-to- > > > use-for-file-locking states that the behaviour is undefined. If that is true > > > it would be a show stopper for using file locking IMO. /home on NFS is not > > > very uncommon... For more exotic unices I would not be surprised if lockf() > > > had bugs even on non-network file systems. > > > > If I interpret the link correct, then undefined behaviour occurs if using > > fcntl on one side and lockf on other. This is not the case here.
I don't interpret it that way. The part about the NFS warning is unrelated to the first part about using lockf and fcntl. > > > > As a compromise maybe we could keep the code, but only activate it by a > > > special configure switch which is off by default and has a big fat warning > > > that it may cause severe problems if lockf() does not behave? > > > > Nothing happens here, if lock does not function correctly. The worst is old behaviour, i.e without lock. > > Error case is handled this way. > > I really don't see any risk. > > > > > Then people > > > interested in parallel testing could still use locking, but the risk for all > > > others is zero. For 2.2 I'd suggest to switch to a qt or boost solution, > > > since these are implemented by people who understand more about locking than > > > all of us, and the test coverage is hopefully also better. > > > > > > > > > Georg > > > > > > > Kornel
