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

[Matt Caswell]

On 24/11/15 15:16, Jonathan Larmour wrote:
> On 23/11/15 20:34, Matt Caswell wrote:
>> On 23/11/15 17:49, Nico Williams wrote:
>>
>>> 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.
> 
> I hope there will be the ability to plug in different operating systems
> and it's not hard coded to just these choices. There are embedded systems
> which use OpenSSL which do not have POSIX thread APIs (POSIX is very
> heavyweight for many).
> 
> For example, GCC abstracts their threading dependenencies with a "gthread"
> API which OS implementers can write against. What would be bad would be
> direct calls to pthread* dotted around the OpenSSL code base.

We are talking specifically about the new async functionality here. The
three implementations are all you get for that. That has no impact on
the rest of OpenSSL functionality. So if you happen to be on a non-posix
and non-windows platform then OpenSSL will function as it does today.
You just don't get the new async functionality on top.

There are pthread references in one (internal) header file and one c
source code file. If the new threading API discussed elsewhere in this
thread goes ahead, then those references would be replaced with calls to
that instead.

Matt