Re: layout return - final update ?

> > Previously what we discussed was the last CLOSE for the file/client
> pair.
>
>
> OK, but the proposed text you supplied is not clear on that point.
>
>
> > That said, I'm not sure about multiple filehandles representing the
> same file.
>
> Another issue that needs to be clarified in the text.

> > This approach seems valid but it complicates the case of layouts not
> marked as return_on_close that survived a previous last CLOSE as these
> will not be affected now.
>
>
> If we are talking about layout not marked return-on-close that were
> sent before the first return-on-close layout, then I think that the
> text you proposed is exactly the same in this respect.  Or am I
> missing something here?
>
>
> > Since we are talking about losing the layout on the last CLOSE from
> the client of that file a catch all approach would be simpler.
>
> I'm not sure that that is so.  First of all, it is very
> natural/required for clients and servers to have data structures
> representing open files, and linking return-on-close layout  to these
> seems relatively straightforward.  on the other hand, I would not
> expect clients and servers to always have an infrastructure to keep
> track of client/fh or client/file pairs and thus always be able to see
> when a last close is being done.  To top it all off, you may
> have racing closes so last-close-at-issue may not be the same as
> last-close-at-receipt.  Also closes and opens can race.  Those sorts
> of considerations led to me thinking associating a layout with a
> specific open file was simpler or at least it made my head hurt less.