[lldb-dev] Getting ConnectionFileDescriptor working on Windows

[Zachary Turner]

Unless you're using a connection string, the instantion site would just
instantiate the exact thing it wants.  e.g.

ConnectionTcpListen *listener = new ConnectionTcpListen();
listener->Connect();
listener->GetBoundPort();

something like that.

For the connection string case, you would call a factory method that
returns a Connection *

On Thu, Oct 2, 2014 at 10:29 AM, Todd Fiala <tfiala at google.com> wrote:

> Hey Zachary,
>
> >> 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.
>
> 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?
>
>
>
>
>
> On Thu, Oct 2, 2014 at 10:04 AM, Zachary Turner <zturner at google.com>
> wrote:
>
>> On Wed, Oct 1, 2014 at 1:44 PM, Zachary Turner <zturner at google.com>
>> wrote:
>>
>>>
>>> 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.
>>>
>>
>> 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.
>>
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>
>>
>
>
> --
> Todd Fiala | Software Engineer | tfiala at google.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141002/de945e98/attachment.html>