On 01/13/10 08:21 PM, [email protected] wrote:
On Wed, Jan 13, 2010 at 08:08:15PM -0600, Shawn Walker wrote:
Based on your earlier comments then, they would need their own
timeout mechanism to wait for a specific period of time until the
lock was available.
I don't understand this assertion. All of libc and the kernel have been
written to use locks that don't require timeouts. No caller should have
to wait forever. If you do that's a deadlock and a bug. All I'm
suggesting is that callers either have to decide whether they want to
wait for the operation that's in progress to complete before they take a
turn (block), or whether they want to return to the caller immediately
(non-blocking).
It's very simple. Just as callers don't want to wait for an
indeterminate amount of time for file retrieval by transport, I believe
they don't want to wait an indeterminate amount of time for an image lock.
I personally, as a developer, would not want to wait "forever" for a
lock. For one thing, if my app isn't multi-threaded, I'd have no way to
be responsive to the user or provide progress information to the user.
I have been unable to find any information that indicates how long the
python will wait for a thread lock before timing out (it appears to be
"forever" in my experience) or a file lock.
I'm also going to defer the read lock as that will require
significantly more thought and work and having at least a write lock
in place will be significantly beneficial.
That's fine. I wasn't suggesting that you implement a read lock,
because of the problems that Danek outlined. My point was that callers
who don't have an exclusive lock may still want to watch out for
unexpected failures that may occur as a result of an image-modifying
operation happening on top of them.
Right, I'm aware of the possible consistency issues. However, I believe
them to be fairly minimal thanks to many of the fixes you've done for
manifests and the ones I've done for catalogs.
My thought has been to get the write locking in place and if read
locking becomes a necessity, then we can start looking at that level of
complexity.
Cheers,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
