(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).
On Thu, Oct 2, 2014 at 10:42 AM, Todd Fiala <tfi...@google.com> wrote:
> 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
>
>
--
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
