Re: Name lookup/DNS resolution mechanism of libcurl

2013-04-12 Thread Michael-O
Am 2013-04-10 23:06, schrieb Daniel Stenberg: On Wed, 10 Apr 2013, Michael-O wrote: Add an alias for ENABLE_THREADS_WIN32 as ENABLE_ASYNC_DNS if this define is for DNS only. Threads win22 says absolutely nothing at least to me. We have two different ways to provide asynchronous DNS! Threads

Re: Name lookup/DNS resolution mechanism of libcurl

2013-04-12 Thread Michael-O
Hi Günter, Am 2013-04-11 14:24, schrieb Guenter: Hi Mike, On 10.04.2013 21:54, Michael-O wrote: I strongly support this approach because its clear and makes everything explicit. I would even go one step further: Add an alias for ENABLE_THREADS_WIN32 as ENABLE_ASYNC_DNS if this define is for

Re: Name lookup/DNS resolution mechanism of libcurl

2013-04-12 Thread Michael-O
Hi Günter, Am 2013-04-11 14:24, schrieb Guenter: [..] in addition I've commited another small fix for the c-ares MinGW makefile in order to automatically create ares_build.h when building from Git:

Re: Name lookup/DNS resolution mechanism of libcurl

2013-04-12 Thread Daniel Stenberg
On Fri, 12 Apr 2013, Michael-O wrote: ares: name resolution works flawlessly and fast async: horribly slow as before Please don't call the threaded resolver backend the async one, as the c-ares one is async as well. If the threaded resolver is slow it sounds like something is wrong since I

Re: Name lookup/DNS resolution mechanism of libcurl

2013-04-11 Thread Guenter
Hi Mike, On 10.04.2013 21:54, Michael-O wrote: I strongly support this approach because its clear and makes everything explicit. I would even go one step further: Add an alias for ENABLE_THREADS_WIN32 as ENABLE_ASYNC_DNS if this define is for DNS only. Threads win22 says absolutely nothing at

Re: Name lookup/DNS resolution mechanism of libcurl

2013-04-10 Thread Gisle Vanem
Guenter li...@gknw.net wrote: How can USE_THREADS_WIN32 both be defined and set to 0? The USE_THREADS_WIN32 == 0 part is superfluous AFAICS. well, simply by -DUSE_THREADS_WIN32=0 ... I think you know I already knew that. Just that it's highly suspicious that it was needed. I forgot the

Re: Name lookup/DNS resolution mechanism of libcurl

2013-04-10 Thread Guenter
hi Gisle, On 10.04.2013 12:37, Gisle Vanem wrote: Guenter li...@gknw.net wrote: How can USE_THREADS_WIN32 both be defined and set to 0? The USE_THREADS_WIN32 == 0 part is superfluous AFAICS. well, simply by -DUSE_THREADS_WIN32=0 ... I think you know I already knew that. sorry; I didnt

Re: Name lookup/DNS resolution mechanism of libcurl

2013-04-10 Thread Michael-O
Am 2013-04-09 21:10, schrieb Guenter: Hi Mike, On 09.04.2013 20:46, Michael-O wrote: Am 2013-04-09 20:31, schrieb Guenter: yes, today commited two patches - one for curl and one for c-ares ... Do you want to to clone from Git and test it? sure, that would be great! But remember that Daniel

Re: Name lookup/DNS resolution mechanism of libcurl

2013-04-10 Thread Michael-O
Am 2013-04-10 04:40, schrieb Yang Tse: Hi Gün, On Wed, Apr 10, 2013, Guenter li...@gknw.net wrote: honestly I'm not happy with that hack, and if someone has something better in mind please speak up! Modify Makefile.m32 in order to make it define one out of three possibilities ENABLE_ARES,

Re: Name lookup/DNS resolution mechanism of libcurl

2013-04-10 Thread Daniel Stenberg
On Wed, 10 Apr 2013, Michael-O wrote: Add an alias for ENABLE_THREADS_WIN32 as ENABLE_ASYNC_DNS if this define is for DNS only. Threads win22 says absolutely nothing at least to me. We have two different ways to provide asynchronous DNS! Threads and c-ares. -- / daniel.haxx.se

Re: Name lookup/DNS resolution mechanism of libcurl

2013-04-09 Thread Michael-O
Am 2013-04-02 00:43, schrieb Guenter: Hi Michael, On 01.04.2013 23:24, Michael-O wrote: Am 2013-04-01 22:52, schrieb Guenter: 1st we need to know if this is also an issue with the default windows resolver; so have you also tested with a non-c-ares build? If it only occures with c-ares then

Re: Name lookup/DNS resolution mechanism of libcurl

2013-04-09 Thread Guenter
Hi Mike, On 09.04.2013 20:01, Michael-O wrote: Günter, were you able to look at the Makefiles of c-ares and curl? yes, today commited two patches - one for curl and one for c-ares ... Gün. --- List admin:

Re: Name lookup/DNS resolution mechanism of libcurl

2013-04-09 Thread Michael-O
Am 2013-04-09 20:31, schrieb Guenter: Hi Mike, On 09.04.2013 20:01, Michael-O wrote: Günter, were you able to look at the Makefiles of c-ares and curl? yes, today commited two patches - one for curl and one for c-ares ... Do you want to to clone from Git and test it?

Re: Name lookup/DNS resolution mechanism of libcurl

2013-04-09 Thread Guenter
Hi Mike, On 09.04.2013 20:46, Michael-O wrote: Am 2013-04-09 20:31, schrieb Guenter: yes, today commited two patches - one for curl and one for c-ares ... Do you want to to clone from Git and test it? sure, that would be great! But remember that Daniel might at any time tag and release ...

Re: Name lookup/DNS resolution mechanism of libcurl

2013-04-09 Thread Daniel Stenberg
On Tue, 9 Apr 2013, Guenter wrote: But remember that Daniel might at any time tag and release ... so only a short while for last-minute hot-fixes :-P EXactly. Please be careful with last-minute pushes now. My plan is to release what's HEAD in git in 14-15 hours or so. -- / daniel.haxx.se

Re: Name lookup/DNS resolution mechanism of libcurl

2013-04-09 Thread Gisle Vanem
Guenter li...@gknw.net wrote: On 09.04.2013 20:01, Michael-O wrote: Günter, were you able to look at the Makefiles of c-ares and curl? yes, today commited two patches - one for curl and one for c-ares ... Thanks for fixing this. I wrote about this in this thread:

Re: Name lookup/DNS resolution mechanism of libcurl

2013-04-09 Thread Guenter
Hi Gisle, On 10.04.2013 00:07, Gisle Vanem wrote: Thanks for fixing this. I wrote about this in this thread: http://curl.haxx.se/mail/lib-2013-01/0131.html earlier this year. Your patch below looks good here. Except: +#if !defined(USE_ARES) !defined(USE_THREADS_WIN32) # define

Re: Name lookup/DNS resolution mechanism of libcurl

2013-04-09 Thread Yang Tse
Hi Gün, On Wed, Apr 10, 2013, Guenter li...@gknw.net wrote: honestly I'm not happy with that hack, and if someone has something better in mind please speak up! Modify Makefile.m32 in order to make it define one out of three possibilities ENABLE_ARES, ENABLE_SYNC_DNS or ENABLE_THREADS_WIN32.

Re: Name lookup/DNS resolution mechanism of libcurl

2013-04-02 Thread Michael-O
Hi Günter, Am 2013-04-02 00:43, schrieb Guenter: I have built now c-ares 1.9.1 with 'mingw32-make -f Makefile.m32' and tried to compile curl against it: 1. Added #define HTTP_ONLY and uncommented #define USE_ARES in config-win32.h 2. Set LIBCARES_PATH=E:\Downloads\c-ares-1.9.1 3. Finally

Re: Name lookup/DNS resolution mechanism of libcurl

2013-04-01 Thread Guenter
Hi Michael, On 01.04.2013 12:37, Michael-O wrote: As a side note: when running the configure script in cygwin either for curl or c-ares the script hangs on checking types of args and return type for recvfrom... [1] Though my machine is quite old, the script runs in a decent time except that

Re: Name lookup/DNS resolution mechanism of libcurl

2013-04-01 Thread Guenter
Michael, On 31.03.2013 17:18, Michael-O wrote: I am on Windows XP SP3 32 bits, I have compiled curl with MingW32 with GCC 4.5.2. you should upgrade to a newer MinGW version; in the past it turned out that exactly this version had some issues [1][2] ... Gün. [1]

Re: Name lookup/DNS resolution mechanism of libcurl

2013-04-01 Thread Michael-O
Am 2013-04-01 14:23, schrieb Guenter: Michael, On 31.03.2013 17:18, Michael-O wrote: I am on Windows XP SP3 32 bits, I have compiled curl with MingW32 with GCC 4.5.2. you should upgrade to a newer MinGW version; in the past it turned out that exactly this version had some issues [1][2] ...

Re: Name lookup/DNS resolution mechanism of libcurl

2013-04-01 Thread Michael-O
Am 2013-04-01 14:06, schrieb Guenter: Hi Michael, On 01.04.2013 12:37, Michael-O wrote: As a side note: when running the configure script in cygwin either for curl or c-ares the script hangs on checking types of args and return type for recvfrom... [1] Though my machine is quite old, the

Re: Name lookup/DNS resolution mechanism of libcurl

2013-04-01 Thread Gisle Vanem
Michael-O 1983-01...@gmx.net wrote: Jackpot! No proxies but I found several addresses in 192.168.56.* This is the VirtualBox (version 4.1.24 installed) Host-Only Network adapter. I have disabled it, and boom curl resolves immediately. A bug in VirtualBox I would guess. Some similar issue is

Re: Name lookup/DNS resolution mechanism of libcurl

2013-04-01 Thread Guenter
Hi Gisle, On 01.04.2013 17:51, Gisle Vanem wrote: BTW. Gunter, your testspeed.bat file writes the test-file to disk and then deletes it right after. IMHO when testing just network speed, (and rule out a slow disk) you could write to the NUL-device and possibly eliminate some timing errors:

Re: Name lookup/DNS resolution mechanism of libcurl

2013-04-01 Thread Michael-O
Am 2013-04-01 17:18, schrieb Michael-O: Am 2013-04-01 16:19, schrieb Guenter: Hi Michael, On 01.04.2013 12:37, Michael-O wrote: This is what I have assumed, it's my setup. How come that other applications resolve quite fast? some things you should check: - disable automatic proxy

Re: Name lookup/DNS resolution mechanism of libcurl

2013-04-01 Thread Guenter
Hi Michael, On 01.04.2013 22:36, Michael-O wrote: I have created an issue for this: https://www.virtualbox.org/ticket/11663 Daniel, you may want to add this as a known issue. 1st we need to know if this is also an issue with the default windows resolver; so have you also tested with a

Re: Name lookup/DNS resolution mechanism of libcurl

2013-04-01 Thread Guenter
Hi Michael, On 01.04.2013 23:24, Michael-O wrote: Am 2013-04-01 22:52, schrieb Guenter: 1st we need to know if this is also an issue with the default windows resolver; so have you also tested with a non-c-ares build? If it only occures with c-ares then this is only an issue with this lib, but