> From: owner-openssl-us...@openssl.org [mailto:owner-openssl- > us...@openssl.org] On Behalf Of Jens Maus > Sent: Wednesday, 25 June, 2014 14:07 > > Am 25.06.2014 um 18:22 schrieb Michael Wojcik > <michael.woj...@microfocus.com>: > > > [...] > > Now, if you need additional application-specific information in the > callback, the best thing is to add it as external data in the SSL object: > > > > /* Create an index for our data in the SSL object */ > > int get_index(void) { > > /* Serialize as necessary */ > > static int index = -1; > > if (index < 0) index = SSL_get_ex_new_index(...); > > return index; > > } > > > > /* After creating the SSL object */ > > SSL_set_ex_data(conn, get_index(), my_data_ptr); > > > > ... > > > > /* In the verify callback, or wherever */ > > my_data_ptr = SSL_get_ex_data(conn, get_index()); > > > > But if all you need in the callback is the SSL object, you needn't worry > about all that. > > Exactly, I need more than just the plain SSL object within the verify > callback because I want to store the individual verify callback results in a > connection specific variable as pointed out in my earlier post. > > Now that you have provided the above pseudo-code and due to the point that I > read the documentation about SSL_set_ex_data() I perfectly understand what > Viktor meant. The only thing that still worries me is that particular > get_index() function and the point that you use a static int variable inside > there. The reason for that is, that in multithreaded environments that > actually would involve locking access to "index" via a separate mutex which > IMHO is sub-optimal, to say the least.
No serialization is necessary around the use of "index". Serialization is necessary in get_index(), which is invoked relatively rarely: when a conversation is created and when the verify callback is called. Neither of those are in the inner loop, and worrying about serialization there is definitely premature optimization. get_index() serializes only to ensure that SSL_get_ex_new_index is called only once during the process lifetime. You can omit serialization if, for example, you can ensure that you invoke SSL_get_ex_new_index only from one thread (typically the initial thread, before any others are created). > In addition, when doing parallel > connections with unique SSL* pointers per connection the above would fail > since get_index() will only return the index number of the first get_index() > call in the first SSL connection. Yes, that's what it should do. It should always return the same value. > But if two or more parallel SSL connections > are initiated you would AFAICS require a unique index variable per running > SSL*. No, that's not how it works. You need one index value per item to be stored in a given SSL object. You have one item to store - a pointer to your application data - in each SSL object. You'll use the same index value for that item in each SSL object. -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
