Am 25.11.2013 um 13:01 schrieb Vincent van Ravesteijn <v...@lyx.org>:
> > > On Mon, Nov 25, 2013 at 11:50 AM, Kornel Benko <kor...@lyx.org> wrote: > Am Montag, 25. November 2013 um 08:22:27, schrieb Vincent van Ravesteijn > <v...@lyx.org> > > On Tue, Nov 19, 2013 at 9:55 PM, Kornel Benko <kor...@lyx.org> wrote: > > > > > Am Dienstag, 19. November 2013 um 21:06:21, schrieb Georg Baum < > > > georg.b...@post.rwth-aachen.de> > > > > Kornel Benko wrote: > > > > > > > > > Trying to lock with > > > > > open(lock_file.c_str(), O_CREAT|O_EXCL|O_SYNC|O_RDWR, 0666); > > > > > seams to work here. So no fcntl anymore. > > > > > > > > This is not portable either. > > > > > > > > > > I know. Scott and I are testing with lockf() now. > > > > > > > Georg > > > > > > Kornel > > > > > > Why did you commit this non-portable code anyway ? > > 1.) Because we need it for parallel tests. > 2.) What is non-portable? Everything in src/support/filetools.cpp is guarded > by some #ifdef. > Also this code. > If the needed function lockf() is not available, nothing happens. > > > Vincent > > Kornel > > 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). We can never be sure that there is no platform out there which > causes this code to fail. I'm also not sure whether the code is fixing a bug, > or facilitating some tests ? > > IMO, the fact that the code is between #ifdef's doesn't make it portable. IMHO, you are changing the rules. There is plenty of non-portable code in LyX if this would be the rule. I think, we should discuss the meaning of "portable code" then. Another move to improve the situation would be to present a code fragment or a pointer to some example code how to solve the locking issue on Windows. Stephan
