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 _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
