more re: cbrecall race

> I like the idea of having a synchronization "barrier" like you
> suggest below.  In case the client does not recognize the stateid
> in the callback, it should wait until any outstanding opens for
> the filehandle indicated in the CB_RECALL are replied and
> then reexamine the CB_RECALL stateid.

Except that, if the file is being created (or the client hasn't done a
lookup before the open), the client doesn't know the file handle.
(I'd agree that, if the client knows the file handle, that has the nice
 effect of reducing the size of the outstanding opens list, often to
 only one.)

>>If the above for loop takes quite a while, that's ok, since the server
>>expects to wait quite a while for the Delegreturn (probably returning
>>NFS4ERR_DELAY to the other client with the conflicting request).
>
>I'm not so sure about that... the spec says:
>   The client should reply to the callback immediately.  Replying does
>   not complete the recall except when an error was returned.  The
>   recall is not complete until the delegation is returned using a
>   DELEGRETURN.
Oops, yes, you're correct. My choice of words for "quite a while" wasn't
appropriate. I was thinking along the lines of "the short period of
time it takes for the Open replies to arrive". But, you are correct
that it can't wait very long. (I think my server gives up waiting for
a callback reply after 5 seconds.)

So, I think it would be ok (at least for my server) if:
"quite a while" <= 2sec