On 01/13/10 07:21 PM, [email protected] wrote:
On Wed, Jan 13, 2010 at 06:03:43PM -0600, Shawn Walker wrote:
Yes, to ensure these commands could work (assuming everything else
is ok) if they are not a privileged user:
pkg install -nv
pkg image-update -nv
...etc.
That's the only reason. If that isn't worthwhile, I can remove that
bit. Of course, this only works right now if all the manifests have
already been retrieved anyway.
I'm trying to discern the use for the image's NRLock in this situation.
If the install/image-update -nv can't modify the image, is it necessary
for the client to hold this lock without making use of flock? Would it
be better to instead set a read-lock with flock in this case?
So the idea was to minimally lock. That is, only lock for write
operations. The point of using the NRLock() is simply to prevent
multiple locks of the same image object due to broken/bad logic within
the same process. In short, one operation at a time using the image object.
Python will quite happily let you call lockf() on the same file multiple
times within the same process, so I don't see how lockf could replace
NRLock.
I'm still not convinced that there isn't value here in the timeout
logic. Since the logic here is nearly identical to that used by
python's own mechanism for threading conditions, couldn't the same
problems happen?
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
Even if I took the approach of "wait" or "don't wait", how do I ensure
callers have control over how long to wait without doing this?
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?
Because this is a generic API thing and I don't know how long different
clients for different applications feel it is appropriate to block for a
lock.
I'm not endorsing Python's locking strategy. If the interpreter puts
itself to sleep during timeouts instead of using the underlying C
syncrhonization objects, then yes, Python's threading is going to suffer
from the same kind of fairness and scheduling problems when locks are
contended.
It does; see the wait routine starting at line 228 of
/usr/lib/python2.6/threading.py.
I'm not saying python is the model citizen here, but I figured that a
similar set of logic would work no worse than using python's own
mechanism for conditional timeouts on locks (thread locks only; doesn't
appear to have one for files).
The file is always opened with 'a+', what am I missing? The pydoc
for lockf says I should check for EAGAIN and EACCES.
If you don't ever expect to open/lock the file in read-only mode then
you can ignore this.
At the moment, yes, it never opens it in read-only mode. There are no
plans to do otherwise at the moment.
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
