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: libcurl read-like interface
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: XSLT2.0 via curl-library <curl-library_at_cool.haxx.se>
Date: Sat, 26 Dec 2020 09:57:21 +0100
True and duly noted Daniel!
Fortunately http/1.1 is simple enough, especially when downloading the
"body" of a file (with Connection: close), you must admit that redoing
what libcurl does here amounts to nothing.
I am even glad with avoiding a "full relay copy" (every bit of
efficiency helps when writing a "filesystem") and with EAGAIN: it
perfectly fits the use case (parallel out of order reads)!
Since being able to get a good working "read-like" interface is an
extreme simplification and performance boost for my program, it is the
solution I have chosen to explore.
As you write yourself: it is a question of balance!
IMHO, the biggest issue with read-like on top of libcurl's current
callbacks (fcurl) is "excess bytes" that are pulled out of the socket.
Pardon me if I am a bit abrasive here, but wouldn't the same remark
apply: why should a user library manage those "excess bytes" that are
natively taken care of by the kernel in socket functions (recv/read)?
I'll change it back to using the whole of libcurl if/when it becomes
possible to get a "decent" read-like other than using curl_easy_recv(),
which I doubt will be an easy task considering the current architecture
of libcurl.
Also as demonstrated by the lack of interest about fcurl, writing a fuse
driver (filesystem) might be one of those extremely rare occasions where
a good working read-like interface makes a huge difference: efficiency +
simpler code. So I understand libcurl has other much higher priorities
than doing it, and unfortunately I don't feel "libcurl-skilled" enough
myself to propose a (huge) PR + new API for that matter.
Subsidiary question, I have noted that changing the socket to "blocking"
(with fcntl) seems to work perfectly, at least for http/1.1 GET. I don't
really need it (quite the opposite), but was just testing performance:
it does not seem to help either! Would such a change be a problem in
other uses of curl_easy_recv()?
Cheers
Alain
> We discourage users from using curl_easy_recv() for doing any protocol
> that libcurl implements natively. Mostly because you need to pretty
> much re-implement everything yourself instead of letting libcurl do
> what it was designed to do.
>
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2020-12-26
Date: Sat, 26 Dec 2020 09:57:21 +0100
True and duly noted Daniel!
Fortunately http/1.1 is simple enough, especially when downloading the
"body" of a file (with Connection: close), you must admit that redoing
what libcurl does here amounts to nothing.
I am even glad with avoiding a "full relay copy" (every bit of
efficiency helps when writing a "filesystem") and with EAGAIN: it
perfectly fits the use case (parallel out of order reads)!
Since being able to get a good working "read-like" interface is an
extreme simplification and performance boost for my program, it is the
solution I have chosen to explore.
As you write yourself: it is a question of balance!
IMHO, the biggest issue with read-like on top of libcurl's current
callbacks (fcurl) is "excess bytes" that are pulled out of the socket.
Pardon me if I am a bit abrasive here, but wouldn't the same remark
apply: why should a user library manage those "excess bytes" that are
natively taken care of by the kernel in socket functions (recv/read)?
I'll change it back to using the whole of libcurl if/when it becomes
possible to get a "decent" read-like other than using curl_easy_recv(),
which I doubt will be an easy task considering the current architecture
of libcurl.
Also as demonstrated by the lack of interest about fcurl, writing a fuse
driver (filesystem) might be one of those extremely rare occasions where
a good working read-like interface makes a huge difference: efficiency +
simpler code. So I understand libcurl has other much higher priorities
than doing it, and unfortunately I don't feel "libcurl-skilled" enough
myself to propose a (huge) PR + new API for that matter.
Subsidiary question, I have noted that changing the socket to "blocking"
(with fcntl) seems to work perfectly, at least for http/1.1 GET. I don't
really need it (quite the opposite), but was just testing performance:
it does not seem to help either! Would such a change be a problem in
other uses of curl_easy_recv()?
Cheers
Alain
> We discourage users from using curl_easy_recv() for doing any protocol
> that libcurl implements natively. Mostly because you need to pretty
> much re-implement everything yourself instead of letting libcurl do
> what it was designed to do.
>
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2020-12-26