On 04/10/2017 03:21 PM, Rainer Jung wrote:
Am 10.04.2017 um 22:41 schrieb Jacob Champion:
A few questions for the list while I'm brainstorming the best way to fix
- What is the oldest version of OpenSSL we'll support for the 2.4.x
line? Will that version change in 2.next?
For 2.4.0 it was discussed originally in May/June 2010. The original
proposal was dropping support < 1.0.0, but we ended up in supporting
everything starting with 0.9.7 (Threads was: "RFC: drop support for
OpenSSL < 1.0 in trunk/2.3?"):
Excellent, thanks for the history!
2.next: that would be up for discussion like it was done for 2.4 in
2010. I guess we would look again at what current OS distributions provide.
Okay. I'll be the first to push for dropping support for anything no
longer supported by OpenSSL upstream -- that would leave us with 1.0.2
and 1.1.0 -- but unfortunately I suspect we will need to drop to 1.0.1
to deal with some common long-term-release distributions that are still
And I'm not looking forward to the inevitable Mac conversation. That's
for another thread, I guess.
- Does anyone have a clever way to check, during configuration time,
that errno is threadsafe? My plan was to spin up two threads in a config
test program and see if the address of errno was different.
I tried it and it does not detect the threadsafe errno when using
-D_REENTRANT. See below.
...oh. So errno is actually threadsafe, but its "address" is the same in
every thread? Interesting. In that case, my original question was not
actually what I wanted to ask.
What I actually want to know is whether the address of errno can be used
as a makeshift thread ID, because that's what the default implementation
in OpenSSL uses. For platforms on which that isn't true (looks like
Solaris is one), we either have to provide our own callback, which may
cause a crash during server startup, or have the user upgrade to 1.1.0,
where the threadid callback isn't needed at all.
So it looks like my test program might still be a possible solution for
detecting whether we need a callback at configure time, unless anyone
knows of a platform where two thread-local errnos can have the same
address some of the time and different addresses at other times...