Re: [racket-dev] the preferences file under Windows
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. Done (Windows only). The `racket/file' library now provides `preferences-lock-file-mode', which reports the style of locking being used. DrRacket, for example, may need to use that function --- instead of testing whether the current platform is Windows --- to determine whether it can try to steal a lock by deleting the lock file. (As far as I know, there's no way to steal a Windows-implemented file lock. The lock will be released when the holding process is terminated.) The default handling of lock errors in `get-preference' is to wait a little while and try again. On the first failure, the handler waits 0.01 seconds, then it waits 0.02 seconds, then 0.04 seconds, then 0.08 seconds, then 0.16 seconds, and then it gives up with an exception. This default is implemented by a `make-handle-get-preference-locked' function provided by `racket/file'. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] the preferences file under Windows
20 minutes ago, Matthew Flatt wrote: The `racket/file' library now provides `preferences-lock-file-mode', which reports the style of locking being used. DrRacket, for example, may need to use that function --- instead of testing whether the current platform is Windows --- to determine whether it can try to steal a lock by deleting the lock file. (As far as I know, there's no way to steal a Windows-implemented file lock. The lock will be released when the holding process is terminated.) The default handling of lock errors in `get-preference' is to wait a little while and try again. On the first failure, the handler waits 0.01 seconds, then it waits 0.02 seconds, then 0.04 seconds, then 0.08 seconds, then 0.16 seconds, and then it gives up with an exception. This default is implemented by a `make-handle-get-preference-locked' function provided by `racket/file'. Not too important now, but wouldn't it be easier to do the same thing on unix using flock()? -- ((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
[racket-dev] the preferences file under Windows
Currently, the `get-preference' and `put-preferences' functions from `racket/file' (which are used by DrRacket and other Racket tools) use the write-to-temp-file-and-rename approach to atomic file update. There's a lock to keep multiple writers from trying to update the file, but no lock for readers. As explained in my previous message, that doesn't work for Windows. The writer lock is implemented by the existence of a lock file. That is, a writer cannot proceed unless it is able to create the lock file, and if some other process has created the lock file, then creation of the lock file by other processes fails (so they know that the file is locked). That much seems fine for Windows. The problem under Windows is to prevent readers from interfering with a writer --- since having a file open to read interferes with update --- the same as other writers. Option 1: Readers could take the lock on the preferences file in the same way as writers. The drawback of this option is that readers need write access to the directory containing the preferences file, since the lock is implemented by creating a file. Does that matter? It sounds wrong to me, but maybe it's just fine. Option 2: Use Windows file locking, and pick a new name for the preferences file under Windows. It takes a few steps to explain the new-name part... Not coincidentally, I recently added `port-try-file-lock?' and `port-file-unlock' to Racket, so OS-supported file locking is an option. (An evt form for locks would be nice, but OS APIs for file locking make that difficult or impossible.) Unfortunately, you can only hold the lock on a file if the file is open --- and having the preferences file open is the root of the problem for moving a new file into place. You can write to a file while holding a lock, of course, but writing directly to the data file risks losing information if the write is interrupted. We could solve this sub-problem by having two files: the first holds the preferences content, and the second exists only to be locked and unlocked. That way, holding a lock doesn't interfere with replacing the data file. 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. That's why this option includes picking a new name for the preferences file (and its accompanying lock file) under Windows. The existing preferences file would be used as a read-only fallback when no file exists with the new preferences-file name. Any opinions? Or does anyone see other options? _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] the preferences file under Windows
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? -- ((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
Re: [racket-dev] the preferences file under Windows
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. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] the preferences file under Windows
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
Re: [racket-dev] the preferences file under Windows
On Thu, Jan 13, 2011 at 4:36 PM, Matthew Flatt mfl...@cs.utah.edu 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. Also, I think we would have had to do that regardless, unless we wanted the installation process to create the lockfile or something. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] the preferences file under Windows
On Thu, Jan 13, 2011 at 4:42 PM, Eli Barzilay e...@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? Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
