I've been looking at the PID file creation mechanism we currently use. It goes through a loop in an attempt to create the PID file, and if one is there it attempts to remove it if the PID it contains no longer exists (there are checks for shared memory usage as well).
This could be cleaned up rather dramatically if we were to use one of the file locking primitives supplied by the OS to grab an exclusive lock on the file, and the upside is that, when the locking code is used, the postmaster would *know* whether or not there's another postmaster running, but the price for that is that we'd have to eat a file descriptor (closing the file means losing the lock), and we'd still have to retain the old code anyway in the event that there is no suitable file locking mechanism to use on the platform in question. The first question for the group is: is it worth doing that? The second question for the group is: if we do indeed decide to do file locking in that manner, what *other* applications of the OS-level file locking mechanism will we have? Some of them allow you to lock sections of a file, for instance, while others apply a lock on the entire file. It's not clear to me that the former will be available on all the platforms we're interested in, so locking the entire file is probably the only thing we can really count on (and keep in mind that even if an API to lock sections of a file is available, it may well be that it's implemented by locking the entire file anyway). What I had in mind was implementation of a file locking function that would take a file descriptor and a file range. If the underlying OS mechanism supported it, it would lock that range. The interesting case is when the underlying OS mechanism did *not* support it. Would it be more useful in that case to return an error indication? Would it be more useful to simply lock the entire file? If no underlying file locking mechanism is available, it seems obvious to me that the function would have to always return an error. Thoughts? -- Kevin Brown [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
