I'd like to use standard flock() locks on the files if possible, because of the nature of the application. The files I'm using aren't just internal files; they're files that other processes access too. Using a custom locking scheme would, unfortunately, defeat this mechanism.
I've come up with two other ideas; unfortunately, neither is particularly portable:
- Fork off a separate daemon on startup, and have the request forks pass the names of which files to lock/unlock to it. This daemon would then maintain the locks. Unfortunately, this method would only work on systems where locks are advisory (not Windows or OS/2), since otherwise I couldn't write to the file in the next request.
- Fork off a separate daemon on startup, and have the request forks pass file descriptors (using Socket::PassAccessRights) that they've locked, then pass them back for unlocking. Although this method seems more proper, it is no better than method 1 since Socket::PassAccessRights only works on *NIX systems, and according to the docs, doesn't work particularly well because the file descriptor passing code in the kernel is buggy.