On Fri, Feb 14, 2014 at 6:40 PM, Argyrios Kyrtzidis <[email protected]>wrote:
> > On Feb 14, 2014, at 9:26 AM, Rafael Espíndola <[email protected]> > wrote: > > >> So you’re suggesting something like this: > >> > >> class AbstactFileSystem { > >> … > >> class FileDescriptor { > >> public: > >> virtual ErrorOr<Status> status() = 0; > >> virtual error_code getBuffer(…) = 0; > >> virtual error_code close() = 0; > >> }; > >> ... > >> }; > > > > That looks odd. If we can keep it to one virtual interface (like in > > the patch) that would probably be better. On llvm a file descriptor in > > always an int. There is some desire to use a file handles on windows, > > but that is also just a abstract pointer. > > > > Can't we make the file handle an arbitrary uintptr_t sized object? The > > FileSystem is then able to interpret it in any way it wants. > > I find it natural, the file descriptor encapsulates the file operations > that you perform on a “file entity” (which can be a virtual file or > whatever) and this is what we are modeling. > > I would find it unnatural that you have a series of multiplexed > AbstractFileSystem objects and you constantly have to thread through them > uintptr_t's that every AFS object has to say whether it understands that > particular uintptr_t or not. > it could be complicated to have them cooperating on the interpretation of > the uintptr_t. > Why wouldn't a multi-plexing AbstractFileSystem implementation exactly know which FDs go to which one of its file system operations? A non-multi-plexing implementation could then just assert the FD is one of its own. It feels rather natural to me that if you have multiple layers of implementations that make up a "tree" of file systems, a request would go through all the layers until landing at the lowest one...
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
