HwangDongJun commented on code in PR #12831: URL: https://github.com/apache/gluten/pull/12831#discussion_r4369324665
########## cpp/velox/compute/VeloxBackend.cc: ########## @@ -191,6 +192,9 @@ void VeloxBackend::init( hiveConnectorConfig_ = createHiveConnectorConfig(backendConf_); + // Make sure the statically linked OpenSSL can find trusted certificates before any filesystem creates an HTTP client. + ensureTlsTrustStore(); Review Comment: Update: the call now sits right after glog is initialized, at the beginning of VeloxBackend::init (a90489e7c). On top of the reasoning above I checked it: glibc's setenv takes a lock but getenv does not, and adding a new variable reallocates the environ array, which is the case that matters here. In the JDK 17 sources the JVM only reads the environment at startup and when writing a crash report, and the JIT compiler threads never read it. I preloaded a getenv/setenv tracer in local-mode runs on Rocky 8.9 and Ubuntu 22.04 (40 runs: 20 before and 20 after moving the call): setenv(SSL_CERT_FILE) takes about 10 us, no getenv call from another thread happened inside that window or within 100 us of it, and the closest read by another thread was the JVM startup one, about 6 s earlier. This is observation, not a proof: only local mode, only calls that go through getenv, and I could not test a distributed run. The only way to remove the risk completely is not to call setenv at all, which i s why the question in my earlier comment about keeping the second commit is still open. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
