On Wed, Jan 13, 2010 at 05:39:06PM -0800, 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.
Ok, but the current implementation doesn't use any read locking in flock, just exclusive locking. That renders most of this moot, correct? -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
