[racket-dev] the preferences file under Windows

From: Robby Findler (robby at eecs.northwestern.edu)
Date: Thu Jan 13 17:45:07 EST 2011

On Thu, Jan 13, 2011 at 4:42 PM, Eli Barzilay <eli at barzilay.org> 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?


Posted on the dev mailing list.