[openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread

[Matt Caswell]

On 23/11/15 17:49, Nico Williams wrote:
> [Resend, with slight edits.]
> 
> [Viktor asked me for my advice on this issue and bounced me the post
>  that I'm following up to.  -Nico]
> 
> The summary of what I've to say is that making libcrypto and libssl need
> -lpthread is something that does require discussion, as it will have
> detrimental effects on some users.  Personally, I think that those
> detrimental effects are a good thing (see below), but nonetheless I
> encourage you to discuss whether this is actually what OpenSSL should
> do.  In particular, it may be possible to avoid -lpthread on some
> systems and still get a subset of lipthread functionality from libc or
> the compiler (e.g., thread-locals), and that may be worth doing.
> 
> On a slightly related note, I asked and Viktor tells me that fiber
> stacks are allocated with malloc().  I would prefer that they were
> allocated with mmap(), because then you get a guard page.  A guard page
> would allow one to safely tune down fiber stack size to the whatever
> OpenSSL actually needs for a given use.

Interesting. I'll take a look at that.

> Still, if -lpthread avoidance were still desired, you'd have to find an
> alternative to pthread_key_create(), pthread_getspecific(), and friends.

Just a point to note about this. The async code that introduced this has
3 different implementations:

- posix
- windows
- null

The detection code will check if you have a suitable posix or windows
implementation and use that. Otherwise the fallback position is to use
the null implementation. With "null" everything will compile and run but
you won't be able to use any of the new async functionality.

Only the posix implementation uses the pthread* functions (and only for
thread local storage). Part of the requirement of the posix detection
code is that you have "Configured" with "threads" enabled. This is the
default. However it is possible to explicitly configure with
"no-threads". This suppresses stuff like the "-DRENENTERANT" flag. It
now will also force the use of the null implementation for async and
hence will not use any of the pthread functions.

One other option we could pursue is to use the "__thread" syntax for
thread local variables and avoid the need for libpthread altogether. An
earlier version of the code did this. I have not found a way to reliably
detect at compile time the capability to do this and my understanding is
that this is a lot less portable.

Matt