headers
Daniel Stenberg | 19 May 2008 13:31
Picon
Favicon
Gravatar

Bug#478864: curl: (6) Resolving host timed out: (fwd)

Hey

Here's another Debian bug report on curl that clearly actually is about 
c-ares...

-- 

  / daniel.haxx.se

---------- Forwarded message ----------
Date: Thu, 1 May 2008 19:01:30 +0500
Subject: Bug#478864: curl: (6) Resolving host timed out:

Package: curl
Version: 7.18.1-1
Severity: important
Tags: ipv6

After recent upgrade curl stopped working:

% curl http://www.debian.org/
curl: (6) Resolving host timed out: www.debian.org

After adding ipv4 nameserver entry to /etc/resolv.conf but with
ipv6-only http_proxy curl exits with

% curl http://www.debian.org/
curl: (5) Could not resolve host: www.debian.org (DNS server returned answer with no data)

This is probably caused by libc-ares support (see also #476735) and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Stenberg | 21 May 2008 09:51
Picon
Favicon
Gravatar

release time?

Hey friends,

It's probably about time we put a tarball together and made a new c-ares 
release.

Is there anything in particular we should get done before this happens?

--

-- 

  / daniel.haxx.se
Permalink | Reply | 7 comments |
headers
Eino Tuominen | 21 May 2008 16:53
Picon
Picon

About thread safety

Hi,

I tried to read through the docs but didn't see this one mentioned: can 
is it safe to call e.g. ares_gethostbyname() using channel initialized 
on another thread? Basically I want to do this on a multithreaded app 
(c-ish pseudocode):

Thread A:

ares_init(channel);

for (;;) {
	select();
	ares_process();

Thread B (and others):

ares_gethostbyname(channel, ...);

In preliminary tests I have found this working well, I just want to make 
sure I'm not doing anything overly stupid. Idea is to have just one (or 
a few if the server is something like Sun T2000) ares instance and pass 
the results from callback function to the other thread. If this is not 
safe, can I just protect calls to ares_* functions with mutexes? If yes, 
which functions must be protected?

Or, do I have to pass the request over to the thread that initialized 
the channel and have it call ares_gethostbyname().

--

--
(Continue reading)

Permalink | Reply | 1 comment |
headers
Yang Tse | 21 May 2008 19:18
Picon

Re: release time?

2008/5/21, Daniel Stenberg wrote:

> It's probably about time we put a tarball together and made a new c-ares
> release.
>
> Is there anything in particular we should get done before this happens?

Besides testing build process on several systems, nothing here before
next release. One week would be more than enough for this.

Which would be the release date ?

--

-- 
-=[Yang]=-
Permalink | Reply | 2 comments |
headers
Daniel Stenberg | 21 May 2008 22:12
Picon
Favicon
Gravatar

Re: About thread safety

On Wed, 21 May 2008, Eino Tuominen wrote:

> I tried to read through the docs but didn't see this one mentioned: can is 
> it safe to call e.g. ares_gethostbyname() using channel initialized on 
> another thread?

As long as the threads never ever use the "channel" pointer at the same time 
you can pass it around as much as you want.

--

-- 

  / daniel.haxx.se
Permalink | Reply | 0 comments |
headers
Daniel Stenberg | 21 May 2008 22:19
Picon
Favicon
Gravatar

Re: release time?

On Wed, 21 May 2008, Yang Tse wrote:

> Besides testing build process on several systems, nothing here before next 
> release. One week would be more than enough for this.
>
> Which would be the release date ?

How about May 29th or so?

--

-- 

  / daniel.haxx.se
Permalink | Reply | 1 comment |
headers
Yang Tse | 22 May 2008 06:35
Picon

Re: release time?

2008/5/21, Daniel Stenberg wrote:

> How about May 29th or so?

It's OK for me.

--

-- 
-=[Yang]=-
Permalink | Reply | 0 comments |
headers
Yang Tse | 22 May 2008 19:20
Picon

Re: release time?

2008/5/21, Daniel Stenberg wrote:

> Is there anything in particular we should get done before this happens?

There is a minor issue with version number but I don't know how you
prefer to address it.

Currently when maketgz runs, the configure.ac file that will be
distributed is exactly the configure.ac with no modification. And as
it is right now the AC_INIT line would need to be updated to 1.5.2 in
CVS before release time. Another option would be to have maketgz copy
configure.ac-rel over configure.ac. Or any other clever thing you
whip.

--

-- 
-=[Yang]=-
Permalink | Reply | 3 comments |
headers
Daniel Stenberg | 22 May 2008 19:42
Picon
Favicon
Gravatar

Re: release time?

On Thu, 22 May 2008, Yang Tse wrote:

> Currently when maketgz runs, the configure.ac file that will be distributed 
> is exactly the configure.ac with no modification. And as it is right now the 
> AC_INIT line would need to be updated to 1.5.2 in CVS before release time. 
> Another option would be to have maketgz copy configure.ac-rel over 
> configure.ac. Or any other clever thing you whip.

Ah, good catch. I already have this fancy hook in Makefile.am that includes 
anything named *.dist instead of the file without that extension, so it was 
easy to have maketgz make a configure.ac.dist file and get that included...

This should work with the fix I've just committed.

--

-- 

  / daniel.haxx.se
Permalink | Reply | 2 comments |
headers
Yang Tse | 23 May 2008 02:39
Picon

Re: release time?

2008/5/22, Daniel Stenberg wrote:

> This should work with the fix I've just committed.

Yes it does!

Some more bits... Files currently not included in distribution tarball:

ares_getopt.h - Should probably be added to ahost_SOURCES,
adig_SOURCES and acountry_SOURCES. Or maybe adding it to EXTRA_DIST in
Makefile.am is more simple.

buildconf - It might be interesting to distribute it also.

FILES - We should remove it from CVS, or update its contents and
include it in the distribution tarball.

get_ver.awk and maketgz are also excluded from distribution tarball.

--

-- 
-=[Yang]=-
Permalink | Reply | 1 comment |

Gmane