Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: Name resolution timeout not respected, Curl_resolver_kill() hangs.
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Woody via curl-library <curl-library_at_lists.haxx.se>
Date: Tue, 16 Nov 2021 15:59:44 +0100
Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Tue, 16 Nov 2021, Woody wrote:
> > It was just a test and it worked, but obviously it raises more doubts than
> > those it solves... :-)
>
> Doesn't it confirm that this is exactly this issue? And your change has the exact same properties that I mentioned: it skips waiting for the thread which has gone awol and therefore this risks leaking memory.
>
> But for example in the case of the curl command line tool which exits immediately afterward, such a leak wouldn't matter. That thread join code was once added just to remove such a memory leak risk when running tools that check for them.
>
> The only half-decent fix for this that I can think of is that we add an option to the library that the application can set that allows it to return early.
>
> Or can we do better?
I must admit I didn't go so deep. As I said I just tried a fast and dirty
solution to test if I found the right place and understood the problem.
In case of error, couldn't we somehow "detach" the thread instead of
skipping the join()? Would it not be cleaner?
Date: Tue, 16 Nov 2021 15:59:44 +0100
Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Tue, 16 Nov 2021, Woody wrote:
> > It was just a test and it worked, but obviously it raises more doubts than
> > those it solves... :-)
>
> Doesn't it confirm that this is exactly this issue? And your change has the exact same properties that I mentioned: it skips waiting for the thread which has gone awol and therefore this risks leaking memory.
>
> But for example in the case of the curl command line tool which exits immediately afterward, such a leak wouldn't matter. That thread join code was once added just to remove such a memory leak risk when running tools that check for them.
>
> The only half-decent fix for this that I can think of is that we add an option to the library that the application can set that allows it to return early.
>
> Or can we do better?
I must admit I didn't go so deep. As I said I just tried a fast and dirty
solution to test if I found the right place and understood the problem.
In case of error, couldn't we somehow "detach" the thread instead of
skipping the join()? Would it not be cleaner?
-- Best regards. Woody from WiBu Systems AG. -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2021-11-16