--On Monday, April 07, 2008 04:18:49 PM -0400 Jeffrey Altman
<[EMAIL PROTECTED]> wrote:
As opposed to the existing model in which
1. client A requests block byte range write lock on fid 1.2.3
2. server replies EWOULDBLOCK
3. another client drops the held lock
4. server sends client A a callback indicating that the lock state on
fid 1.2.3 has changed
5. client decides whether or not to request the lock again. if so,
go to 1
Actually, last I checked (about 3 seconds ago) the existing model is that
after the server replies EWOULDBLOCK, client A sleeps for 1 second and
tries again. What you describe would be a significant improvement, and
requires only that the clients change, since RXAFS_LockRelease has done a
callback on release of the last lock for some time.
Using multiple callback messages would make it hard to coalesce delayed
callbacks of different types.
Yes, but it might not matter. For one thing, I'm not sure we need to
provide extended notifications from BreakDelayedCallbacks; it may be
sufficient just to do a traditional callback break and let the client sort
it out, at least initially.
Incidentally, I don't think "union is not currently used" is a good
argument for not using it. I'm pretty sure I've actually seen a use
outside of AFS, though I can't find it at the moment, but even if there is
none, it doesn't matter. If it turns out to be buggy, we'll fix it!
-- Jeff
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
