<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Feb 14, 2014, at 9:42 AM, Manuel Klimek <<a href="mailto:klimek@google.com">klimek@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Feb 14, 2014 at 6:40 PM, Argyrios Kyrtzidis <span dir="ltr"><<a href="mailto:kyrtzidis@apple.com" target="_blank">kyrtzidis@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
On Feb 14, 2014, at 9:26 AM, Rafael Espíndola <<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>> wrote:<br>
<br>
>> So you’re suggesting something like this:<br>
>><br>
>> class AbstactFileSystem {<br>
>> …<br>
>> class FileDescriptor {<br>
>> public:<br>
>> virtual ErrorOr<Status> status() = 0;<br>
>> virtual error_code getBuffer(…) = 0;<br>
>> virtual error_code close() = 0;<br>
>> };<br>
>> ...<br>
>> };<br>
><br>
> That looks odd. If we can keep it to one virtual interface (like in<br>
> the patch) that would probably be better. On llvm a file descriptor in<br>
> always an int. There is some desire to use a file handles on windows,<br>
> but that is also just a abstract pointer.<br>
><br>
> Can't we make the file handle an arbitrary uintptr_t sized object? The<br>
> FileSystem is then able to interpret it in any way it wants.<br>
<br>
</div></div>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.<br>
<br>
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.<br>
it could be complicated to have them cooperating on the interpretation of the uintptr_t.<br></blockquote><div><br></div><div>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.</div>
<div>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...</div></div>
</div></div>
</blockquote></div><div><br></div>The “get a file descriptor object” will land on the appropriate AFS which will return a proper implementation to do file operations on.<div><br></div><div>There is no significant difference on the client side (instead of calling a method on the AFS, it calls a method on the FileDescriptor), it may simplify a bit some functions to just accept a FileDescriptor if they only need such a thing (instead of always passing an AFS + FD), and the multiplex implementation becomes simpler.</div></body></html>