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: Timothe Litt <litt_at_acm.org>
Date: Tue, 16 Nov 2021 17:48:42 -0500
On 16-Nov-21 17:24, Daniel Stenberg via curl-library wrote:
> On Tue, 16 Nov 2021, Woody wrote:
>
>> In case of error, couldn't we somehow "detach" the thread instead of
>> skipping the join()? Would it not be cleaner?
>
> I suppose this is where my inexperience with thread programming shines
> through, but yes, I think that sounds exactly what we need!
>
Without looking at the code in question:
If you detach a thread, you need to take care that it doesn't hold any
pointers to stack or heap variables in the parent that might be
deallocated before the detached thread terminates. If you miss this,
you end up with a (usually difficult to debug) bit spray.
If you can't guarantee this, you may need to (atomically)
reference-count shared heap structures, and have the last user (parent
or detached thread) deallocate the structure. You MUST enforce the
guarantee for any stack variables, of course.
Once you detach a thread, you have no control over it. That is, you
can't force it to terminate, nor can you join a detached thread. You
might, via a shared structure, request that it terminate early, but that
requires cooperation. That could work if you are blocking on DNS
resolution, and check when the result eventually returns (or times
out). But you need to account for race conditions.
Fixing this would be a good thing, but care is required to ensure that
the cure isn't worse than the disease.
Received on 2021-11-16
Date: Tue, 16 Nov 2021 17:48:42 -0500
On 16-Nov-21 17:24, Daniel Stenberg via curl-library wrote:
> On Tue, 16 Nov 2021, Woody wrote:
>
>> In case of error, couldn't we somehow "detach" the thread instead of
>> skipping the join()? Would it not be cleaner?
>
> I suppose this is where my inexperience with thread programming shines
> through, but yes, I think that sounds exactly what we need!
>
Without looking at the code in question:
If you detach a thread, you need to take care that it doesn't hold any
pointers to stack or heap variables in the parent that might be
deallocated before the detached thread terminates. If you miss this,
you end up with a (usually difficult to debug) bit spray.
If you can't guarantee this, you may need to (atomically)
reference-count shared heap structures, and have the last user (parent
or detached thread) deallocate the structure. You MUST enforce the
guarantee for any stack variables, of course.
Once you detach a thread, you have no control over it. That is, you
can't force it to terminate, nor can you join a detached thread. You
might, via a shared structure, request that it terminate early, but that
requires cooperation. That could work if you are blocking on DNS
resolution, and check when the result eventually returns (or times
out). But you need to account for race conditions.
Fixing this would be a good thing, but care is required to ensure that
the cure isn't worse than the disease.
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
- application/pgp-signature attachment: OpenPGP digital signature