I see the point, it's not useful if it's only for decoration. It does
feel intuitively right to have txid, if it could be used by a family of
RPCs. Might make for cleaner interfaces for cancellation, abandonment,
(not to mention futures--reversibility, delegation, ...)?
Also note that multiple _reads_ can be going on at once, and you want to
be able to track those, too, so you can avoid letting anyone write while
there's a read in progress.
The fileserver simply assumes that anyone who tries to extend or release
a lock is the caller that actually holds the lock, instead of using a
transaction ID. Let's not make the same mistake here.
I can't see this going wrong. Readers are being counted (effectively
acquiring shared locks). No writer or reader is allowed to force any
locks. Writers will be blocked until all readers are known to be
finished. Do you see scenarios where this pattern is disrupted?
Regards
- Felix
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
