On 02/18/2016 12:25 AM, Daniel Stenberg wrote:
> On Wed, 17 Feb 2016, Avi Kivity wrote:
>
> Hello!
>
>> 1. make ares_socket_t a struct wrapping either an int or a WIN32
>> SOCKET type; any operations on ares_socket_t (close, sendmsg, etc.)
>> will be forwarded to helper functions that extract the fd and call
>> the library function; for example
>>
>> int ares_socket_close(ares_socket_t s)
>> {
>> return sclose(s.fd);
>> }
>
> That sort of wrapping then of course has to be conditionally #ifdef'ed
> on some build thing as we don't want to break existing applications.
>
My intent was on not requiring recompilation or ifdefs, so a single
shared library can work for both the standard socket API and user-space
TCP/IP stacks. I somehow missed that ares_socket_t is a public type :(.
So instead of this, I'd make a new ares_internal_socket_t which will be
used in ares_private.h. The public interface will only use
ares_socket_t, while privately we'll be using a struct wrapper around
it. The intent is that we don't accidentally call a socket API on an
ares_internal_socket_t.
Maybe this is overkill and we can get away by just being careful to
convert all the existing users, and taking care not to add new
violations in the future.
>> 2. add a way to configure function pointers for all the
>> ares_socket_*() functions, with defaults calling to the existing
>> code, and change the ares_socket_*() functions to call these function
>> pointers.
>
> Since it has to be a build-time option anyway, we can just use
> #define'd names for the functions, right? So you'd basically do:
>
> #ifdef MY_MAGIC_TCP_STACK
> #define recvfrom(x,y,z) magic_recvfrom(MAGIC_STACK, x, y, z)
> #endif
>
> ... or did you have something more special in mind?
>
Since I wanted it to be a run-time choice, a function pointer structure
seemed appropriate.
>> Would such a change be acceptable to c-ares?
>
> Yes, we shouldn't have any problems with that.
>
> My advice is to show us your first patch in progress early, so that we
> can discuss the specfic approach before you spend a lot of time on a
> way we possibly don't agree with!
>
Sure, I wanted to see if you were receptive to the use-case. But let's
agree on run-time vs. build-time first.
Received on 2016-02-18