Two minutes ago, Matthew Flatt wrote: > At Thu, 13 Jan 2011 17:29:15 -0500, Eli Barzilay wrote: > > 30 minutes ago, Matthew Flatt wrote: > > > > > > Unfortunately (again), the lock file has to exist alongside the > > > data file, and our existing preferences files are not > > > accompanied by lock files. It's no good assuming that you don't > > > need the lock if there's no lock file present, because the lock > > > file might get created in between the time that you try to use > > > the lock file and the time that you try to open the preferences > > > file. > > > > Why not always use such a lock file, creating it if it's not there > > -- and then you can open it once per process, and lock/unlock it > > for each read/write of the actual file. Does this fail somehow? > > That's a good idea. It's a little bit of option 1, in that a reader > will sometimes need to write a file --- but only in the transitional > case of dealing with an existing preference file without a lock > file.
Yeah... If it wasn't for the "transition", it would have already been there (created when the prefs file is created). (Another point is where the lock file is located, like putting it in some /dev/shm-like place so the file itself becomes just a way to name a kernel lock. I think that I've seen that discussed in some linux context, with a similar sounding locking scheme (where you open the file and then lock it).) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev