Thanks David, #4 seems to be the simplest solution to me. while trying #4, I get exception on windows platform. Usually the excpetion occurs in ERR_clear_error while allocating memory. I call ERR_remove_state() at end of library functions. With single thread it works find. But as soon as I increase the no. of threads, I start to get exception. Is there any kind of locking requirement that is expected?
Pankaj On Sun, May 30, 2010 at 5:28 AM, David Schwartz <dav...@webmaster.com>wrote: > > Pankaj Aggarwal wrote: > > > I am able to think about the following approaches : > > > 1. Keep a record a threads which are spawned. > > > 2. Expose a function from our library for cleanup when the thread exits > > > Is there any other way to avoid the memory leak caused by error queues ? > > There are several: > > 3. Only call OpenSSL functions from threads whose lifetimes are managed by > your library. Dispatch requests that require calls into the library to your > handler threads. So the functions called from the outside look like this: > Allocate and fill out a request object, put it on a processing queue, > unblock/signal an event to wake a worker thread wait for the object to > complete, extract the results. > > 4. Call ERR_remove_state before any function that put things on the OpenSSL > error stack is permitted to return. > > 5. Hook the system's thread shutdown logic (in a platform specific way) so > that you can run ERR_remove_state when a thread terminates. On POSIX > platforms, for example, you can create some thread-specific data whose > destructor calls ERR_remove_state. > > DS > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org >
