Commenting below ...
On 6/28/16 6:42 AM, David Drysdale via c-ares wrote:
> Hi Brad,
>
> This seems to run pretty well -- as you say, it's vastly faster than
> the ./configure variant!
:)
> My main concern would be that having 2 parallel build systems adds a
> bit more friction to the
I've just confirmed CMake 2.8 (tested 2.8.12.2 on Ubuntu 14.04) works fine,
it doesn't appear I'm depending on any v3 features, so it is safe to reduce
the minimum version.
-Brad
On 6/28/16 7:56 AM, Brad House via c-ares wrote:
Commenting below ...
On 6/28/16 6:42 AM, David Drysdale via c
Why is 16 too few? Do you have more than 8-16 name servers configured?
Remember, it is one fd per nameserver (or possibly 2 if it has to fall back
to TCP), NOT one fd per query, as my original reply stated.
The ares_getsock is what you'd use, and yes, it does have a limit of 16
fds.
-Brad
On
I'm pretty sure c-ares just uses a single socket per nameserver, so to
have more than 16 socks, you'd have to have more than 8 DNS servers (I'm
assuming here that each server tries both UDP, then due to response
overflow has to retry via TCP).
I use c-ares with an event based system where we use
rlimits are already set correctly.
-Brad
On 1/24/17 9:16 PM, Daniel Hardman wrote:
Your program should call setrlimit on startup to change the number of file
descriptors.
See http://unix.stackexchange.com/a/29579.
On Tue, Jan 24, 2017 at 5:14 PM, Brad House via c-ares <c-ares@cool.haxx
spbian arm
On 9/1/16 5:39 PM, Daniel Stenberg wrote:
On Thu, 1 Sep 2016, Brad House via c-ares wrote:
Configure-time type size checks are a really bad idea, especially for things
like Apple (MacOS, iOS) where you could
be building multi-arch, where you run configure once, but the compiler,
So, is this patch being rejected then?
-Brad
On 9/1/16 6:54 PM, Brad House via c-ares wrote:
Hi Daniel,
Based on your reply, I'm thinking you maybe didn't realize I attached a
patch on the original email :)
Most of the attached patch is just removal of unused defines, so if you
did see
On 09/23/2016 05:35 PM, Daniel Stenberg wrote:
> On Fri, 23 Sep 2016, Brad House via c-ares wrote:
>
>> I'd like to re-open the discussion of the last patch I sent via this mailing
>> list: "[PATCH] remove configure-time type size checks"
>>
>> This fixe
On 9/25/16 12:43 PM, Daniel Stenberg wrote:
On Sun, 25 Sep 2016, Brad House wrote:
I should also-recap the GOAL of the patch. The goal is for MacOSX and iOS to
allow multi-arch building.
Right, and I'm looking beyond MacOSX and I want to completely remove the need
to double compile for
I'd like to re-open the discussion of the last patch I sent via this
mailing list:
"[PATCH] remove configure-time type size checks"
This fixes multi-arch building for iOS and MacOSX (without requiring
separate builds and using lipo to join them), and has been tested
across a large number of
depending on any v3 features, so it is safe to reduce
the minimum version.
-Brad
On 6/28/16 7:56 AM, Brad House via c-ares wrote:
Commenting below ...
On 6/28/16 6:42 AM, David Drysdale via c-ares wrote:
Hi Brad,
This seems to run pretty well -- as you say, it's vastly faster than
On 9/27/16 10:26 AM, David Drysdale via c-ares wrote:
On Tue, Sep 27, 2016 at 2:52 PM, Gregor Jasny via c-ares
<c-ares@cool.haxx.se> wrote:
Hi Brad,
On 27/09/2016 13:44, Brad House via c-ares wrote:
I've attached v2 of my CMake patch for c-ares. The changes are:
* Sync with
On 9/27/16 9:52 AM, Gregor Jasny via c-ares wrote:
Hi Brad,
On 27/09/2016 13:44, Brad House via c-ares wrote:
I've attached v2 of my CMake patch for c-ares. The changes are:
* Sync with master (no configure-time type size checks)
* Support iOS multi-arch building
* Require only CMake v2.8
7/09/2016 13:44, Brad House via c-ares wrote:
I've attached v2 of my CMake patch for c-ares. The changes are:
* Sync with master (no configure-time type size checks)
* Support iOS multi-arch building
* Require only CMake v2.8
...
If you don't mind could you please create a pull reque
On 10/03/2016 05:23 AM, Gregor Jasny wrote:
> On 29/09/2016 21:34, Gregor Jasny wrote:
>> On 29/09/2016 14:34, David Drysdale wrote:
>>>
>>> Gregor / Daniel, did you have any thoughts on the CMake change?
>>
>> Yes, I'm reviewing it but the CVE took most of my spare time.
>
> I think as soon as
t;
> Thought maybe it could help. No worries either way,
>
> Brady
>
>
>
>
> On 9/29/16 6:14 AM, Brad House via c-ares wrote:
>> On 9/28/16 9:19 AM, Brad House via c-ares wrote:
>>> On 9/28/16 7:40 AM, David Drysdale wrote:
>>>> Any
On 9/25/16 9:46 AM, Daniel Stenberg wrote:
On Sun, 25 Sep 2016, Brad House wrote:
The *type* detection was not modified in any way what-so-ever by my patch set.
That's what I'm saying. And until we introduce a way to figure out that type in
the public header, we can't remove the
build-time
On 9/25/16 9:30 AM, Daniel Stenberg wrote:
On Sat, 24 Sep 2016, Brad House wrote:
The 'ares_socklen_t' seems to be a particular problem in the current
ares_build.h file that sticks out. How does your
suggested replacement look for that that?
Can you elaborate? CARES_SIZEOF_ARES_SOCKLEN_T
On 9/30/16 3:05 PM, Daniel Stenberg wrote:
On Fri, 30 Sep 2016, Brad House via c-ares wrote:
Anyone have thoughts on this? It would mean less to maintain for sure with
multiple build systems, with the caveat of
it being hard to fix if it doesn't work in the future for some reason
On 10/03/2016 02:03 PM, Brad House via c-ares wrote:
> On 10/03/2016 05:23 AM, Gregor Jasny wrote:
>> On 29/09/2016 21:34, Gregor Jasny wrote:
>>> On 29/09/2016 14:34, David Drysdale wrote:
>>>>
>>>> Gregor / Daniel, did you have any thoughts on th
Pull request made:
https://github.com/c-ares/c-ares/pull/92
On 3/14/17 8:16 AM, Brad House via c-ares wrote:
Sure, I've got a couple of meetings this morning, I'll do it this afternoon
probably.
-Brad
On 3/14/17 8:07 AM, David Drysdale wrote:
Hi Brad,
Actually, a pull request might
, 2017 at 10:50 AM, Brad House via c-ares <c-ares@cool.haxx.se
<mailto:c-ares@cool.haxx.se>> wrote:
I didn't think this would be worthwhile for a pull request since its such a
trivial
patch, but there are a few places where socklen_t is used instead of
ares_socklen_t
Sounds good to me, we've been running a snapshot of master in production which
fixed a bunch of windows issues. I'll review some of the pull requests, I know
I was looking at one regarding the Windows search domains earlier. Otherwise
I think master is in pretty good shape.
-Brad
On 05/23/2017
Yep, original was definitely broken, major brainfart there on my part, can't
even
see what I was thinking, at a minimum the %8 was in the wrong place.
I've merged that PR, if you want to submit one to make that same exclusion apply
to all systems, I don't see why that wouldn't be allowed since
24 matches
Mail list logo
