<div dir="ltr">(By wrong constructor I mean "wrong class" --- for instance if the Posix ones actually took file descriptors in a constructor for any/all of the impls on Posix-y systems, it would be easy to construct the wrong kind of class in a POSIX environment and aside from the bound port part, it would be hard to tell the wrong derived class was being used).</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 2, 2014 at 10:42 AM, Todd Fiala <span dir="ltr"><<a href="mailto:tfiala@google.com" target="_blank">tfiala@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">The concept all sounds good to me.<div><br></div><div>I suppose as long as the constructors/factories that create these make it hard for the non-Windows platforms to accidentally introduce shared code that really uses the wrong constructor (which at the file-descriptor level might be entirely not obvious and hidden on non-Windows), then that would be good. Otherwise I could see you having run-time breaks that only show up on Windows but merrily work on other platforms.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 2, 2014 at 10:39 AM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">That's correct. ConnectionTcpListen in particular will probably have a different impl on posix, because that one use case is the only reason for the GetBoundPort() method. So removing all of the bound port logic from the interface and implementation of the other types of connections seems desirable.</div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 2, 2014 at 10:37 AM, Todd Fiala <span dir="ltr"><<a href="mailto:tfiala@google.com" target="_blank">tfiala@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span><div>> <span style="font-size:13px;font-family:arial,sans-serif">Unless you're using a connection string, the instantion site would just instantiate the exact thing it wants. e.g.<br></span>> <span style="font-size:13px;font-family:arial,sans-serif">ConnectionTcpListen *listener = new ConnectionTcpListen();</span></div><div><span style="font-size:13px;font-family:arial,sans-serif"><br></span></div></span><div><span style="font-size:13px;font-family:arial,sans-serif">Ok - so these classes will exist across all OS builds, where on Windows you get impls that have different details for each derived class, and on POSIXy items the derived classes are either derive with no impl different from base class, or typedefs (?) that map to the single base class, and everything just works. Is that about right?</span></div><div><span style="font-size:13px;font-family:arial,sans-serif"><br></span></div><div><span style="font-size:13px;font-family:arial,sans-serif">I'm just looking at it from the angle of shared code using those new classes when they're not using the connection string approach.</span></div><div><span style="font-size:13px;font-family:arial,sans-serif"><br></span></div><div><span style="font-size:13px;font-family:arial,sans-serif">Sounds reasonable to me.</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 2, 2014 at 10:34 AM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Unless you're using a connection string, the instantion site would just instantiate the exact thing it wants. e.g.<div><br></div><div>ConnectionTcpListen *listener = new ConnectionTcpListen();</div><div>listener->Connect();</div><div>listener->GetBoundPort();</div><div><br></div><div>something like that.</div><div><br></div><div>For the connection string case, you would call a factory method that returns a Connection *</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 2, 2014 at 10:29 AM, Todd Fiala <span dir="ltr"><<a href="mailto:tfiala@google.com" target="_blank">tfiala@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hey Zachary,<span><div><br></div><div><span style="font-family:arial,sans-serif;font-size:13px">>> 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.</span><br></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div></span><div><span style="font-family:arial,sans-serif;font-size:13px">What would the instantiation sites for these classes look like? Would it be a call into some kind of Host level "'Create{Socket,File,Pipe}(...)" factory method that knows what kind of underlying object to create based on that? In which case you can fork off to the right versions for Windows, while POSIX-y systems would (as you noted) be able to use a single file-descriptor-based impl?</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Thu, Oct 2, 2014 at 10:04 AM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Wed, Oct 1, 2014 at 1:44 PM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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></blockquote><div><br></div></span><div>The more I think about this, the more I feel like it's the right approach (it might even be the only approach that even works, I can't really come up with anything else that solves the problem, much less does it nicely). We've already got cases where people create a ConnectionFileDescriptor of a specific type, and use it in a way that would break if it weren't of that type. Separating out the cases into different classes this way would allow these cases to be cleaner, as many methods that are publicly exposed on CFD, and some of the class members as well are specific to the type of fd being wrapped. So the interfaces of the other types could become cleaner as well. </div></div></div></div>
<br></div></div>_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
<br></blockquote></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><table cellspacing="0" cellpadding="0" style="color:rgb(136,136,136);font-family:'Times New Roman'"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Todd Fiala |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Software Engineer |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:tfiala@google.com" style="color:rgb(17,85,204)" target="_blank"><span style="background-color:rgb(255,255,204);color:rgb(34,34,34);background-repeat:initial initial">tfiala@google.com</span></a></td><td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"><br></td></tr></tbody></table><br></div>
</font></span></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><table cellspacing="0" cellpadding="0" style="color:rgb(136,136,136);font-family:'Times New Roman'"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Todd Fiala |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Software Engineer |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:tfiala@google.com" style="color:rgb(17,85,204)" target="_blank"><span style="background-color:rgb(255,255,204);color:rgb(34,34,34);background-repeat:initial initial">tfiala@google.com</span></a></td><td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"><br></td></tr></tbody></table><br></div>
</div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><table cellspacing="0" cellpadding="0" style="color:rgb(136,136,136);font-family:'Times New Roman'"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Todd Fiala |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Software Engineer |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:tfiala@google.com" style="color:rgb(17,85,204)" target="_blank"><span style="background-color:rgb(255,255,204);color:rgb(34,34,34);background-repeat:initial initial">tfiala@google.com</span></a></td><td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"><br></td></tr></tbody></table><br></div>
</div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><table cellspacing="0" cellpadding="0" style="color:rgb(136,136,136);font-family:'Times New Roman'"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Todd Fiala |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Software Engineer |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:tfiala@google.com" style="color:rgb(17,85,204)" target="_blank"><span style="background-color:rgb(255,255,204);color:rgb(34,34,34);background-repeat:initial initial">tfiala@google.com</span></a></td><td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"><br></td></tr></tbody></table><br></div>
</div>