<div dir="ltr">I'm trying to get ConnectionFileDescriptor working on Windows.  Because select() has completely different semantics on Windows as on posix, it won't work for this purpose, so It hink the best approach is to re-write ConnectionFileDescriptor for windows.  I've already submitted <a href="http://reviews.llvm.org/D5548">a patch</a> that moves CFD to Host so that I can provide a different implementation for Windows.  <div><br></div><div>However, I'm not sure if just providing a Windows implementation is sufficient, due to the very nature of this class.  In short, the things you can do with a generic file descriptor on Windows are very different than the things you can do with a file descriptor on posix.  And unfortunately, certain assumptions about what you can do with a file descriptor are baked into the code that uses CFD as well as CFD itself (after all, its design alone implies that all these different use cases of file descriptors are interchangeable).</div><div><br></div><div>One of the more awkward things to deal with is that CFD provides a constructor that takes a file descriptor.  Inside, it *assumes* that this fd represents an actual file, but in practice we sometimes give it other things to this constructor.</div><div><br></div><div>I've broken down all the cases of where we use this constructor as follows:</div><div><br></div><div>SBCommunication::AdoptFileDesriptor - passes in whatever fd the user decides to give it, and treats it as a file.  <br></div><div><br></div><div>ScriptInterpreterPython::ExecuteOneLine - passes in the fd of a pipe, CFD doesn't have any way to know it's a pipe though, and treats it as a file.<br></div><div><br></div><div>GDBRemoteCommunicationServer::SetSTDIOFileDescriptor - Not sure, I think this is always an actual file, but maybe not.<br></div><div><br></div><div>Process::SetSTDIOFileDescriptor - Same as before, I think this is always an actual file, but maybe not.<br></div><div><br></div><div>I'm not really sure how to deal with this on Windows.  We need to know what it *actually* is.  Furthermore, file descriptors in general don't provide the necessary functionality required to be able to implement interrupting as used by CFD.  For that we need the native OS type for whatever these objects are.  For sockets that means an object of type SOCKET.  For pipes and files it means a HANDLE.  "Here's an fd, do something with it" just isn't enough of, or the right kind of information to be able to do the right thing.</div><div><br></div><div>AFAICT I only need to deal with the above 4 cases.  </div><div><br></div><div>The first case I can deal with by #ifdefing it out on Windows returning an error that says "sorry, not supported on Windows".  </div><div><br></div><div>For the second case, I'm not sure what to do because I don't actually understand how this function works or why this level of complexity is required.</div><div><br></div><div>For the third and fourth cases, maybe I can just assume they're files?</div><div><br></div><div>I was thinking about splitting CFD into multiple classes, one for each type of descriptor.  A FileConnection, PipeConnection, TcpSocketConnection, ListeningConnection, etc.  Then, the caller would have to instantiate the right kind.  This has its own set of problems, but at least seems to solve the problem of requiring the creator of the CFD to specify what they're actually giving us.  On posix in cases where it's user specified or don't know, it seems we could just create a FileConnection and that would be equivalent to the current behavior, since it seems to treat everything the same anyway.</div><div><br></div><div>thoughts?</div></div>