On 01/13/10 08:04 PM, [email protected] wrote:
You probably want to give callers the option to block, unless they don't have the privilege to write to the lock file. Danek's comments to raise an interesting point about consistency. If you're unable to open the lockfile '+a', you still probably want to try 'r' to see if a client is presently modifying the image. If it is, you may want to avoid reading data that can become inconsistent as part of the update. Unfortunately, you still can run into problems if the image gets exclusively locked while the install -nv is in progress somewhere else. In that case, you may want to check the lockfile in the unexpected exception handler and suppress any exceptions that occur as a result of the lockfile being changed out from underneath the unprivileged process.
I don't see the point of providing an option to block if the caller can't specify a timeout, since I don't believe that any caller is going to want to wait forever (an indefinite amount of time) for a lock.
Based on your earlier comments then, they would need their own timeout mechanism to wait for a specific period of time until the lock was available.
I'm also going to defer the read lock as that will require significantly more thought and work and having at least a write lock in place will be significantly beneficial.
-- Shawn Walker _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
