I think we could also put the seeding of the rand lib in the global init function
since i dont see any ref in the doc that it should be thread specific

"T. Bharath" wrote:

> > ERR_remove_state(0); (this is thread specific and has to be called in
> > every thread that uses the ssl lib)
>
> >So SSL_free() doesn't take care of that?
> no it doesnt.ERR_remove_state(0) is needed to clean up some hash entries and
> certain other things stored in the sslcontext
>
> > EVP_cleanup();
> >What's that doing?
> This is the clean up routine for the
> SSLeay_add_ssl_algorithms();
>
> >Two functions for the "global" scope, only to be done once per application,
> >unregarding on how many threads or uses of libcurl there is gonna be:
>
> > curl_global_init()
> >curl_global_cleanup()
>
> ... then, to make older applications still run fine, I'll have a check in
> >curl_easy_init() that if curl_global_init() hasn't been run, invokes it.
> >It'll make that older applications will continue to leak memory due to not
> >calling curl_global_cleanup()... but I can't see how I could solve this.
> >Anyone?
>
> Sounds good but yes it will not be backward compatible
>
> Daniel Stenberg wrote:
>
> > On Mon, 28 May 2001, T. Bharath wrote:
> >
> > (The docs for OpenSSL really is in a sorry state, which leads to problems
> > like these...)
> >
> > > Regarding use of SSL in libCurl i find that SSL_load_error_strings(); and
> > > SSLeay_add_ssl_algorithms(); are called in Curl_SSLConnect().(i use a
> > > older version 7.4 so i found them in UrgSSLConnect)
> >
> > It is named Curl_SSLConnect() in recent versions. The functionality hasn't
> > changed much though.
> >
> > > These two functions are to be called once in a process Now consider a
> > > scenario involving multiple threads, where Curl_SSLConnect() gets called
> > > in multiple threads these functions are invoked many times.
> >
> > Indeed...
> >
> > > I am really not sure the implications of invoking the functions mutiple
> > > times but one thing is we dont call the clean up functions causing
> > > leakage(i couldnt find them in the current version either)
> >
> > Agreed. If nothing else, it'll at least cause memory leaks.
> >
> > But libcurl can't know if it'll be used for multiple threads or not, why it
> > has to init those things once for every curl_easy_init() call. An alternative
> > would be some kind of option to tell libcurl to not do these initialisations
> > and instead have you (the application) do the "only one init" call... ?
> >
> > Anyway, I'll make two new functions for "global" SSL inits and cleanups.
> >
> > > ERR_remove_state(0); (this is thread specific and has to be called in
> > > every thread that uses the ssl lib)
> >
> > So SSL_free() doesn't take care of that?
> >
> > > EVP_cleanup();
> >
> > What's that doing?
> >
> > > ERR_free_strings();
> >
> > I'll make that a "global" free.
> >
> > > I am using a older version of the libCurl so i tried placing them in
> > > urlfree() (iam not sure where you place them inthe recent version)
> >
> > The whole concept of which things that get freed where was changed quite a
> > lot since the introduced of persistent connections in libcurl 7.7...
> >
> > > but this was leading to a crash when multiple threads were involved since
> > > EVP_cleanup();
> >
> > > ERR_free_strings(); should be called only on application cleanup.
> >
> > > So the best option was to remove SSL_load_error_strings(); and
> > > SSLeay_add_ssl_algorithms(); from Curl_SSLConnect() and put them in a
> > > global function that gets called only once at application startup and put
> > > the clean up routines EVP_cleanup(); ERR_free_strings(); in another
> > > global function that has to be called on application exit. and retain
> > > ERR_remove_state(0) in urlfree() since this is needed for thread clean up
> >
> > This sounds like a good idea, but also quite "big" changes. I think I'll
> > introduce this concept:
> >
> > Two functions for the "global" scope, only to be done once per application,
> > unregarding on how many threads or uses of libcurl there is gonna be:
> >
> > curl_global_init()
> > curl_global_cleanup()
> >
> > ... then, to make older applications still run fine, I'll have a check in
> > curl_easy_init() that if curl_global_init() hasn't been run, invokes it.
> > It'll make that older applications will continue to leak memory due to not
> > calling curl_global_cleanup()... but I can't see how I could solve this.
> > Anyone?
> >
> > > I cannot send a diff since i am not using the latest version
> >
> > Ah, but you _should_ use a later version! ;-)
> >
> > Thanks a lot for this feedback.
> >
> > --
> > Daniel Stenberg -- curl dude -- http://curl.haxx.se/
> >
> > _______________________________________________
> > Curl-library mailing list
> > Curl-library_at_lists.sourceforge.net
> > http://lists.sourceforge.net/lists/listinfo/curl-library
>
> _______________________________________________
> Curl-library mailing list
> Curl-library_at_lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/curl-library

_______________________________________________
Curl-library mailing list
Curl-library_at_lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/curl-library
Received on 2001-05-28