On Wed, May 29, 2024 at 10:17 AM Christian Brauner <brauner@xxxxxxxxxx> wrote: > > > Is it honestly worth encoding all that complexity into rust's file > > > implementation itself right now? It's barely understandable to > > > non-rust experts as it is right now. :) > > > > > > Imho, it would seem a lot more prudent to just have something simpler > > > for now. > > > > The purpose of the changes I've made are to prevent data races on the > > file position. If we go back to what we had before, then the API does > > not make it impossible for users of the API to cause such data races. > > > > That is the tradeoff. > > Right. Sorry, there's some back and forth here. But we're all navigating > this new territory here and it's not always trivial to see what the > correct approach is. Yeah of course. You've been very helpful in that regard, and I'm grateful for that. > I wonder what's better for now. It seems that the binder code isn't > really subject to the races we discussed. So maybe we should start with > the simpler approach for now to not get bogged down in encoding all > subtle details into rust's file wrapper just yet? Yeah, maybe. But I think that if we can accurately represent the requirements of the interface, then that would be preferable. Perhaps we can tweak it to make it easier to understand, without giving up accuracy? One of the reasons that the current API is confusing is that the types are called `File<NoFdgetPos>` and `File<MaybeFdgetPos>`. These names _sound_ like their purpose is to keep track of whether or not the file came from an `fdget_pos` call or not, but that is not the case. Instead, let's call them something else. We can have two files: File and LocalFile. This name accurately conveys the main difference between them. File can be transferred across thread boundaries. LocalFile cannot. Now, it is still the case that `fget` will return a `LocalFile`, which may be confusing. But we can document it like this: 1. On `fget`'s docs, we explain that to get a `File`, you need to convert it using the `assume_not_in_fdget_pos_scope` function. We do not explain why in the docs for `fget`. 2. We can put an explanation of why in the docs for the function `assume_not_in_fdget_pos_scope`. I think it's possible to design an API like this where the complexities about `fdget_pos` are only relevant in a few places. In the rest of the implementation, we simplify the situation to "file is threadsafe" or "file is not threadsafe", and that distinction should be easier to understand than nuances related to `fdget_pos`. Alice
