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

[Jonathan Larmour]

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.

> 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.

Behind the scenes, if pthreads are available on an OS, then the compiler
will probably just end up using pthread functions anyway, meaning there's
no advantage over having just linked against libpthread.

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine