On 01/13/10 07:58 PM, [email protected] wrote:
On Wed, Jan 13, 2010 at 07:33:22PM -0600, Shawn Walker wrote:
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.
If you're trying to prevent concurrent access to the image object by the
same threads in the process, it sounds like you're duplicating a lot of
the functionality of the API's activity lock. Would you look at how
the functionality of the activity lock and the image lock can be
commonized? I think that the activity lock may be redundant if you're
using the image's NRLock to serialize.
Except I'm not. This ensures that internal callers that lock the image
are behaving correctly.
I could do this with a simple boolean flag instead, but that seems
pointless since NRLock() does what I want already.
Again, the whole purpose of using NRLock() is to expose bad internal
logic that is attempting to lock the current image multiple times.
It helped me when I was debugging immensely.
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?
What caller needs control over how long to wait? I tried to lay out the
cases where I thought this lock might get contended, but there didn't
seem to be a plausible explanation for a timeout. Either the caller
needs the lock and must wait, or the caller doesn't want to wait and
should return. What's the use case for a timeout for the API's consumers?
As Danek pointed out though, a caller may not want to wait forever. We
don't know how clients will use the API, and so we can't guess what
their use case is.
My use case was that I didn't want pkg(1) to immediately exit needlessly
with a lock error, so the timeout was my attempt to mitigate that. I
just didn't want to shove the responsibility of timeout code onto
callers and felt it was nice to place it into the api instead.
It was my earnest attempt to slightly reduce potential user frustration
of "it said it was locked by pid XXX, but I don't see one!". In other
words, trying to avoid the "execute pkg in a loop until the lock is
available."
I still don't agree that a timeout isn't potentially useful, but since
there appear to be no firm, existing use cases for it I won't keep the
logic. I'll post a new webrev shortly that always attempts a
non-blocking lock and fails immediately if it can't acquire one.
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
