Bryan Henderson turned the 'initialized' variable for curl_global_init()

                                  Changelog

Daniel (16 January 2006)

- Bryan Henderson turned the 'initialized' variable for curl_global_init()

  into a counter, and thus you can now do multiple curl_global_init() and you

  are then supposed to do the same amount of calls to curl_global_cleanup().

  Bryan has also updated the docs accordingly.

Daniel (13 January 2006)

- Andrew Benham fixed a race condition in the test suite that could cause the

  test script to kill all processes in the current process group!

This release includes the following changes:

 o 

 o curl_global_init() and curl_global_cleanup() are now using a refcount so

   that it is now legal to call them multiple times. See updated info for

   details.

This release includes the following bugfixes:

advice from friends like these:

 Dov Murik, Jean Jacques Drouin, Andres Garcia, Yang Tse, Gisle Vanem, Dan

 Fandrich, Alexander Lazic, Michael Jahn, Andrew Benham

 Fandrich, Alexander Lazic, Michael Jahn, Andrew Benham, Bryan Henderson

        Thanks! (and sorry if I forgot to mention someone)

initializes curl and this call \fBMUST\fP have a corresponding call to

\fIcurl_easy_cleanup(3)\fP when the operation is complete.

If you did not already call \fIcurl_global_init(3)\fP, it will be done

automatically with a default setup when you call \fIcurl_easy_init(3)\fP.

If you did not already call \fIcurl_global_init(3)\fP, 

\fIcurl_easy_init(3)\fP does it automatically.

This may be lethal in multi-threaded cases, since \fIcurl_global_init(3)\fP is

not thread-safe and must not be called more than once (or from more than one

thread). You are strongly adviced to not rely on this automatic behaviour, but

call \fIcurl_global_init(3)\fP yourself properly.

not thread-safe, and it may result in resource problems because there is

no corresponding cleanup.

You are strongly advised to not allow this automatic behaviour, by

calling \fIcurl_global_init(3)\fP yourself properly.

See the description in \fBlibcurl\fP(3) of global environment

requirements for details of how to use this function.

.SH RETURN VALUE

If this function returns NULL, something went wrong and you cannot use the

other curl functions.

.BI "void curl_global_cleanup(void);"

.ad

.SH DESCRIPTION

curl_global_cleanup must be called once (no matter how many threads or libcurl

sessions that'll be used) by every application that uses libcurl, after all

uses of libcurl is complete.

This function releases resources acquired by \fBcurl_global_init\fP.

This is the opposite of \fIcurl_global_init(3)\fP.

You should call \fIcurl_global_cleanup()\fP once for each call you make

to \fIcurl_global_init\fP, after you are done using libcurl.

\fBThis function is not thread safe.\fP You must not call it when any

other thread in the program (i.e. a thread sharing the same memory) is

running.  This doesn't just mean no other thread that is using

libcurl.  Because \fBcurl_global_cleanup()\fP calls functions of other

libraries that are similarly thread unsafe, it could conflict with any

other thread that uses these other libraries.

See the description in \fBlibcurl\fP(3) of global environment

requirements for details of how to use this function.

Not calling this function may result in memory leaks.

.SH "SEE ALSO"

.BR curl_global_init "(3), "

.BR libcurl "(3), "

.BI "CURLcode curl_global_init(long " flags ");"

.ad

.SH DESCRIPTION

This function should only be called once (no matter how many threads or

libcurl sessions that'll be used) by every application that uses libcurl.

This function sets up the program environment that libcurl needs.  Think

of it as an extension of the library loader.

If this function hasn't been invoked when \fIcurl_easy_init(3)\fP is called,

it will be done automatically by libcurl. It is adviced that you do not rely

on this automatic call, but instead call \fIcurl_global_init(3)\fP properly.

This function must be called at least once within a program (a program is

all the code that shares a memory space) before the program calls any other

function in libcurl.  The environment it sets up is constant for the life

of the program and is the same for every program, so multiple calls have

the same effect as one call.

The flags option is a bit pattern that tells libcurl exact what features to

The flags option is a bit pattern that tells libcurl exactly what features to

init, as described below. Set the desired bits by ORing the values together.

In normal operation, you must specify CURL_GLOBAL_ALL.  Don't use any other

value unless you are familiar with and mean to control internal operations

of libcurl.

You must however \fBalways\fP use the \fIcurl_global_cleanup(3)\fP function,

as that cannot be called automatically for you by libcurl.

\fBThis function is not thread safe.\fP  You must not call it when any

other thread in the program (i.e. a thread sharing the same memory) is

running.  This doesn't just mean no other thread that is using

libcurl.  Because \fIcurl_global_init()\fP calls functions of other

libraries that are similarly thread unsafe, it could conflict with any

other thread that uses these other libraries.

See the description in \fBlibcurl\fP(3) of global environment

requirements for details of how to use this function.

Calling this function more than once will cause unpredictable results. If that

is not enough, calling this function from more than one thread may also cause

unpredictable results.

.SH FLAGS

.TP 5

.B CURL_GLOBAL_ALL

.BR curl_global_init_mem "(3), "

.BR curl_global_cleanup "(3), "

.BR curl_easy_init "(3) "

.BR libcurl "(3) "