Rich, How do you mean that the scheme doesn't work with worker threads? Doesn't judicious use of ERR_remove_state overcome any problems of a new job on a given thread "remembering" the error state of the previous job(s)?
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rich Salz Sent: Wednesday, 28 September 2005 1:30 PM To: [email protected] Subject: ideas on replacing where ERR_STATE is stored? An ERR_STATE block (crypto/err.c) is stored in a global hashtable keyed by thread-id. If threads are re-used (like the windows worker thread concept), this scheme doesn't work. It looks like replacing the internal int_thread_get_item/int_thread_set_item pair, or the higher-level ERR_get_state/ERR_remove_state pair is the way to go. The complications are (1) the code tries very hard to not expose any functions or function-dispatch structures; and (2) I need to do this at startup-time, and the code tries VERY hard to make err_fns_check calls all over the place -- that latter part means replacing the ERR_get/remove_state seems like the cleaner solution. Attached is a proposed diff. Any comments? /r$ -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
