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).
Code sample of the threaded reader:
while(!fcurl_eof(fcurl)) {
sz = fcurl_read(buf, 1, BUFSIZE, fcurl);
if (sz > 0) {
wsz = write(STDOUT_FILENO, buf, sz);
if (wsz != sz) {
fprintf(stderr, "write() %ld bytes failed\n", (long)sz);
exit(1);
}
}
if (0 == --chunks) {
curl_easy_pause(fcurl->curl, CURLPAUSE_ALL);
sem_post(&sem[(i + 1) % NTHREADS]);
chunks = CHUNKS;
sem_wait(&sem[i]);
curl_easy_pause(fcurl->curl, CURLPAUSE_CONT);
}
}
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)
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?
Subsidiary question, I have made a version of fcurl totally replacing
mallocs/free by pauses/resume (no multi-threading here!)
The code is shorter and simpler, and let libcurl do its job with memory
management!
Since it is not at all a bug fix (your version was working fine after my
initial PR) but a different algorithm, would you like a PR?
Cheers
Alain
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
