Ok cool yeah I'm just looking for a way to know about semantic errors
before runtime. Sounds good to me.
On Thu, Oct 2, 2014 at 10:50 AM, Zachary Turner <ztur...@google.com> wrote:
> 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 <ztur...@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 <tfi...@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 <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
>>>
>>>
>>
>
--
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
