On Wed, Jan 13, 2010 at 07:46:13PM -0600, Shawn Walker wrote: > On 01/13/10 07:39 PM, Danek Duvall wrote: > >[email protected] wrote: > > > >>I don't understand why the timeout is necessary. Either the caller > >>wants to grab the lock and is willing to wait its turn, or the caller > >>wants to try the lock and return a suitable error message if it is > >>already locked. The timeout doesn't do application code any good, since > >>there's no way to know how long an operation might take. A user who > >>wants to install now, immediately, should not block so that corrective > >>action can occur as soon as possible. A user who is willing to wait for > >>a pending operation to complete can't know the time and must simply > >>block. What value am I missing? > > > >You could have the following scenario: > > > > - we take a read lock for a command which isn't image-modifying, but > > wants consistency: pkg list, for instance (you wouldn't want the > > catalog rewritten while it's trying to read it) > > > > - given the existence of a read lock, we now have an unprivileged DoS -- > > grab the lock for reading and just hang out, preventing anyone from > > installing packages or making other image-modifying operations > > > > - given that, it'd be really nice to be able to override the read lock > > when you know it's safe, or know you don't care about the readers. > > > >I don't know that it's a particularly strong scenario, but it doesn't seem > >all that far-fetched. > > If that's really the only usage case for this, then I'd rather just > always try for a non-blocking lock and simplify the interface.
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. -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
