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
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:
http://svwe10.itex.at/cgit/cgit.cgi/c-ares.git/commit/?id=2004a7a1115e25128170e40470eba8603f7080da
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 DN
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 a
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 le
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
-
Am 2013-04-10 04:40, schrieb Yang Tse:
Hi Gün,
On Wed, Apr 10, 2013, Guenter 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_D
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 m
hi Gisle,
On 10.04.2013 12:37, Gisle Vanem wrote:
"Guenter" 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 think further
"Guenter" 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 reason behin
Hi Gün,
On Wed, Apr 10, 2013, Guenter 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".
Modify
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 USE_THREADS_
"Guenter" 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:
http://curl.haxx.se/mail/lib-2013-01
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
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 ...
so
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?
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: http://cool.haxx.se
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 this
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 compil
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 no
Am 2013-04-01 22:52, schrieb 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; s
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 non-c-are
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 configuration
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 configuration
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"
"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
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 configuration in IE if enabled
Was disabled anyway.
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 configuration in IE if enabled
- check with 'route print' for local proxy (f.e. AVM DSLWeb or
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 scr
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] ...
Gün
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] http://curl.haxx.se/mail/lib-20
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 t
Am 2013-03-31 23:30, schrieb Daniel Stenberg:
On Sun, 31 Mar 2013, Michael-O wrote:
What is so different about the name resolution in libcurl?
Nothing I'm aware of. In window you get the threaded name resolver by
default, but that's been used by fellow (lib)curl users on Windows for
many year
On Sun, 31 Mar 2013, Michael-O wrote:
What is so different about the name resolution in libcurl?
Nothing I'm aware of. In window you get the threaded name resolver by default,
but that's been used by fellow (lib)curl users on Windows for many years
without any problems reported.
As a side
34 matches
Mail list logo
