[lldb-dev] Getting ConnectionFileDescriptor working on Windows

[Zachary Turner]

BTW, in case it wasn't clear, these new typedefs would be used in the
constructors of the derived classes, and not just int.  This way if someone
created the wrong type of derived class, it would break the build on
Windows.

On Thu, Oct 2, 2014 at 10:49 AM, Zachary Turner <zturner at google.com> wrote:

> I plan to define some additional typedefs similar to lldb::process_t and
> lldb::pid_t.  They will be lldb::pipe_t, lldb::socket_t, and lldb::file_t.
> On posix these will all just be typedefed to int.  On Windows they will be
> typedefed to HANDLE, SOCKET, HANDLE, respectively.
>
> That should address that, although Windows may go through some pains
> getting this to work at first since right now fds are pretty prevalent in
> the code.  That's the idea anyway.  If it doesn't work, as a fallback we
> can create a fd based constructor on Windows too and only use it in the
> cases where it's too difficult to propagate the native type up as far as it
> needs to go, but mark it deprecated and encourage people to use the
> appropriate native types going forward.
>
> On Thu, Oct 2, 2014 at 10:44 AM, Todd Fiala <tfiala at google.com> wrote:
>
>> (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 <tfiala at 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 <zturner at 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 <tfiala at 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 <zturner at 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 <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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Todd Fiala | Software Engineer | tfiala at google.com
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Todd Fiala | Software Engineer | tfiala at google.com
>>>
>>>
>>
>>
>> --
>> 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/16680850/attachment.html>