Vincent van Ravesteijn wrote: > Kornel Benko schreef op 25-11-2013 13:20: >> >> Am Montag, 25. November 2013 um 13:01:05, schrieb Vincent van >> Ravesteijn <v...@lyx.org> >> >> > >> >> > The problem is that the commit is touching very essential code. If >> >> > something goes wrong LyX becomes pretty much unusable (e.g. if >> > configure >> >> > isn't run anymore). >> >> This cannot happen. You can't construct such a case.
I am pretty sure I could construct one. See below for one idea, but I have more. If I had more time to actually try it out I would bet;-) > 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. 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? 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
