On Wed, 2017-12-20 at 12:27 +0100, Aris Adamantiadis wrote: > Hi Nikos, > > Libssh by itself is threadsafe. The requirements here are for the > backends. Openssl and libgcrypt (older versions) are far from being > transparent, for the same reason as we did: forcing usage of one of > the > different threading OS APIs would have caused problems sooner or > later, > especially for people who aren't using threads at all. OpenSSL > threading > implementation is/was (did it improve recently) done via callbacks > that > we have to implement. We decided to give a quick solution if you need > pthreads: > > ssh_threads_set_callbacks(ssh_threads_get_pthread()); > ssh_init > <http://api.libssh.org/master/group__libssh.html#ga3ebf8d6920e563f3b0 > 32e3cd5277598e>(); > > and link with libssh_phtreads.so. I think it's an acceptable tradeoff > that will fit 99% of linux/bsd use cases.
The problem that can happen with the global setup approach is that applications which use libssh indirectly (e.g., via libcurl), will not setup anything, and thus at some point crash randomly. This proved to be a very common scenario, that glibc has the pthread mutex locking functions included as stubs. The reason for the stubs is that you don't really need to link to -lpthread to use pthread_mutex_lock(), or create mutexes. You can just use it in a library, and can be assured that the libc stub will do nothing for apps which don't link against libpthread, and will do the expected actions for apps which link against pthreads. Said that, and given that you need locking only for the back-end, on the openssl linkage scenario, you wouldn't need that at all with openssl > 1.1.0 (see [0]), as it is already thread safe. You could use that for earlier version, and provide a library which is unconditionally thread safe. regards, Nikos [0]. https://www.openssl.org/blog/blog/2017/02/21/threads/
