On Wed, Jan 13, 2010 at 08:08:15PM -0600, Shawn Walker wrote: > 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 don't understand this assertion. All of libc and the kernel have been written to use locks that don't require timeouts. No caller should have to wait forever. If you do that's a deadlock and a bug. All I'm suggesting is that callers either have to decide whether they want to wait for the operation that's in progress to complete before they take a turn (block), or whether they want to return to the caller immediately (non-blocking). > 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. That's fine. I wasn't suggesting that you implement a read lock, because of the problems that Danek outlined. My point was that callers who don't have an exclusive lock may still want to watch out for unexpected failures that may occur as a result of an image-modifying operation happening on top of them. -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
