I think I spot an alternate option.
It looks like SSL_set1_verify_cert_store
overrides in the SSL
object the X509_STORE
provided by the global SSL_CTX
object. Further, OpenSSL does an atomic refcount on the X509_STORE
copies.
So, one scheme could be:
X509_STORE *current_x509_store
object. Each time a new SSL
object is made, grab a read lock, invoke SSL_set1_verify_cert_store(ssl, current_x509_store)
, and then release the read lock.X509_STORE *new_x509_store = X509_STORE_new()
, grabs a write lock, calls X509_STORE_free(current_x509_store)
, does current_x509_store = new_x509_store
, then release the write lock.The refcounts are then handled by OpenSSL as opposed to managing them from the Xrootd side; the only blocking is, once an hour, decrementing a refcount and doing an atomic update of a pointer location. Looking at the glibc implementation of the read-write, it seems the cost of the 'read lock' is an atomic increment except in the case when there's a pending write (which again, happens once an hour).
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1