On 20/12/17 13:21, Nikos Mavrogiannopoulos wrote: > 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/ > > Thanks for the pointers. I will have to check if that approach is portable enough. We'd need a mutex somewhere in ssh_init() though because that function cannot be made threadsafe. In the end we can help developers but we can't read the doc for them :)
Aris