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: curl_easy_pause() documentation question
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Tomalak Geret'kal via curl-library <curl-library_at_cool.haxx.se>
Date: Mon, 28 Dec 2020 16:02:33 +0000
On 28/12/2020 10:22, XSLT2.0 via curl-library wrote:
> Hello,
>
> curl_easy_pause() documentation says:
>> While it may feel tempting, take care and notice that you cannot
>> call this function from another thread. To unpause...
>
> I have tested the opposite: we can although the document says "you
> cannot"... with http(s) 1.1, with threads reading in a round robin mode
> -very stupid, but just for testing-, protected by semaphores,
> pausing in one thread and unpausing in another, it works fine (amd64 and
> ARM).
When the documentation of some library says "you can't",
that's a contract. After breaking the contract, maybe you
can make it "safe" for some version with synchronisation in
the calling scope, maybe you can't, maybe it'll change in
the next version, maybe there's an intricacy inside the
library you're not aware of that will blow up one day. You
take on that responsibility and typically should not do so
in production code. The fact remains: the official line that
"you can't" is the base logic to follow.
> The only visible effect is that on "verbose" mode, on my Raspberry Pi 4
> with curl 7.64, it is spitting a ton of messages:
>
> * Expire in 0 ms for 6 (transfer 0x....)
>
> (I can't find this message in the current source of libcurl, and it is
> not displayed either on my Ubuntu's curl 7.68)
That's a temporary issue of unwanted debug output that has
been discussed on the list before and was fixed in a later
version.
> Questions: what could fail here if we do what the documentation says we
> cannot do, but seems to work with proper synchronisation primitives:
> semaphores or the like?
>
> Apart from Async DNS, I can't see any "mutexes" in the library code,
> other protocols have that kind of thing that would make the above code
> enter in a deadlock?
You could work it out from the source code of some
particular version, but why? Just follow the contract.
That's why it exists.
Cheers
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2020-12-28
Date: Mon, 28 Dec 2020 16:02:33 +0000
On 28/12/2020 10:22, XSLT2.0 via curl-library wrote:
> Hello,
>
> curl_easy_pause() documentation says:
>> While it may feel tempting, take care and notice that you cannot
>> call this function from another thread. To unpause...
>
> I have tested the opposite: we can although the document says "you
> cannot"... with http(s) 1.1, with threads reading in a round robin mode
> -very stupid, but just for testing-, protected by semaphores,
> pausing in one thread and unpausing in another, it works fine (amd64 and
> ARM).
When the documentation of some library says "you can't",
that's a contract. After breaking the contract, maybe you
can make it "safe" for some version with synchronisation in
the calling scope, maybe you can't, maybe it'll change in
the next version, maybe there's an intricacy inside the
library you're not aware of that will blow up one day. You
take on that responsibility and typically should not do so
in production code. The fact remains: the official line that
"you can't" is the base logic to follow.
> The only visible effect is that on "verbose" mode, on my Raspberry Pi 4
> with curl 7.64, it is spitting a ton of messages:
>
> * Expire in 0 ms for 6 (transfer 0x....)
>
> (I can't find this message in the current source of libcurl, and it is
> not displayed either on my Ubuntu's curl 7.68)
That's a temporary issue of unwanted debug output that has
been discussed on the list before and was fixed in a later
version.
> Questions: what could fail here if we do what the documentation says we
> cannot do, but seems to work with proper synchronisation primitives:
> semaphores or the like?
>
> Apart from Async DNS, I can't see any "mutexes" in the library code,
> other protocols have that kind of thing that would make the above code
> enter in a deadlock?
You could work it out from the source code of some
particular version, but why? Just follow the contract.
That's why it exists.
Cheers
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2020-12-28