Re: Multi-threading

[Nikos Mavrogiannopoulos <nmav@xxxxxxxxxx>]

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/