[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.
Danek
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
