|
curl-cpp
static c++17 wrapper for curl with -fno-exceptions support
|
|
curl-cpp
static c++17 wrapper for curl with -fno-exceptions support
|
Why make Easy_ref_t RAII-less?
It would simplify design of Easy_ref_t, since it doesn't need to implement RAII-part logic.
It would also make it easier to use member function of Easy_ref_t in Multi_t, provided that libcurl callback provides CURL* and that option CURLOPT_PRIVATE which enables storing any object, isn't support until 7.10.3.
Easy_ref_t's member function cannot be called in multiple threads simultaneously.
Persistent connections means that libcurl can re-use the same connection for several transfers, if the conditions are right.
libcurl will always attempt to use persistent connections. It will by default, cache 5 connections.
Whenever you use Easy_ref_t::perform or Multi::perform/Multi::socket_action, libcurl will attempt to use an existing connection to do the transfer, and if none exists it'll open a new one that will be subject for re-use on a possible following call to these functions.
To allow libcurl to take full advantage of persistent connections, you should do as many of your file transfers as possible using the same handle.
If you use the easy interface, and the Easy_t get destroyed, all the possibly open connections held by libcurl will be closed and forgotten.
When you've created a multi handle and are using the multi interface, the connection pool is instead kept in the multi handle so closing and creating new easy handles to do transfers will not affect them. Instead all added easy handles can take advantage of the single shared pool.
It can also be archieved by using curl::Share_base or curl::Share and enable_sharing(Share_base::Options::connection_cache).
1.8.17
