On Thu, Jan 13, 2011 at 4:42 PM, Eli Barzilay <[email protected]> wrote: > 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).)
Don't we only need this under windows? Robby _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
