cURL / Mailing Lists / curl-library / Single Mail


Re: living without global variables

From: Daniel Stenberg <>
Date: Mon, 28 Nov 2005 17:14:17 +0100 (CET)

On Sun, 27 Nov 2005, Bryan Henderson wrote:

> I have written the code we discussed a while back to make it easier to write
> a program in which libcurl doesn't mess with global state.
> A reminder of the strategy: A libcurl user uses one of two paradigms:
> - traditional and easy: Call curl_global_init() before using libcurl
> and curl_global_cleanup() afterward. Make sure nothing else in your
> program is using libcurl or OpenSSL, Winsock, etc. Create session
> objects with curl_easy_init().
> - private client object: Call (new) curl_client_init() to create a client
> object. Create session objects with (new) curl_easy_init_c() with
> the client handle as argument. By default, nothing that requires
> libcurl to mess with global state works. If user wants it to work,
> he initializes the particular global facility in his own code and
> calls e.g. curl_use_global_openssl() to give libcurl permission to
> use it with a particular client object.

Ok, this looks promising. I do have a few questions/comments to start with:

I'm not saying it is better, but an alternative approach would of course be to
assign the 'client object' to the easy handle with a CURLOPT_* option after it
was created. It would remove the need for curl_easy_init_c()...

Also, I'm not fond of the specific functions added for the single specific
items that (currently) have a global state or a field in the client object:
openssl, gnutls, sock, charset. I prefer a more extensible approach that
allows us to add a new subsystem tomorrow and remote one of the existing the
day after that, without breaking the API/ABI backwards compatibility.

Is there really a need for gnutls global data?

Further, is there a need for the curl_client_global_xxx_ok() public functions?

And if so, I don't see how they can return a 'bool' without us having to do
some nasty typedefing on some places (bool being a newcomer in the C
language). Nasty because it is outside of our name space and so many other
"things" typedefs and deals with bool so that it is likely to cause collisions

  Commercial curl and libcurl Technical Support:
Received on 2005-11-28