The concept all sounds good to me.
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.
On Thu, Oct 2, 2014 at 10:39 AM, Zachary Turner <ztur...@google.com> wrote:
> 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.
>
> On Thu, Oct 2, 2014 at 10:37 AM, Todd Fiala <tfi...@google.com> wrote:
>
>> > Unless you're using a connection string, the instantion site would
>> just instantiate the exact thing it wants. e.g.
>> > ConnectionTcpListen *listener = new ConnectionTcpListen();
>>
>> 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?
>>
>> 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.
>>
>> Sounds reasonable to me.
>>
>>
>> On Thu, Oct 2, 2014 at 10:34 AM, Zachary Turner <ztur...@google.com>
>> wrote:
>>
>>> 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 <tfi...@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 <ztur...@google.com>
>>>> wrote:
>>>>
>>>>> On Wed, Oct 1, 2014 at 1:44 PM, Zachary Turner <ztur...@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@cs.uiuc.edu
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Todd Fiala | Software Engineer | tfi...@google.com
>>>>
>>>>
>>>
>>
>>
>> --
>> Todd Fiala | Software Engineer | tfi...@google.com
>>
>>
>
--
Todd Fiala | Software Engineer | tfi...@google.com
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
