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.
If we really think read locking is necessary too, then we could add that
on later. I'm primarily interested in dealing with the nasty write cases.
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
