-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Jeffrey Altman wrote:
| The problem I see with your approach is that it imposes too much state | on the file server. Or just enough. | The file server needs to be able to deal with the | situations in which either client A is no longer reachable and is | therefore holding the lock when others could be using it; and deal with | the case where client A sends a lock request cancellation message racing | with the lock allocation. That is true. | | The existing model works today but suffers from the failure to know that | the reason a callback was received was because the lock was dropped or | because a Store occurred etc. |> I believe there is a race between A (who received EWOULDBLOCK, and has decided to re-try) and B, who requests an overlapping lock, in the interval between C's release of the contended lock (3) and A's re-execution of its lock request (1). Matt - -- Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 http://linuxbox.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH+pXGJiSUUSaRdSURCJMoAJkB2OI045vqoPVmBw2gn0BHtggB7wCfZAUB 4NX0sa37ote59nrK8+5JmuA= =cX2J -----END PGP SIGNATURE----- _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
