On 20/12/17 11:55, Nikos Mavrogiannopoulos wrote: > On Wed, 2017-12-20 at 10:38 +0100, Andreas Schneider wrote: >> On Tuesday, 12 December 2017 01:25:58 CET Ахриев Альберт wrote: >>> Dear All, >>> >>> As a newcomer I am struggling to understand how to use libssh in >>> multithreaded environment. >>> >>> Very simple question: if application creates in each thread a >>> separate >>> instance of ssh session, which runs completely independently from >>> other >>> instances, is that enough to guarantee thread-safety? In other >>> words, are >>> the state variables of each session really independent? >> No, that's not enough see: >> >> http://api.libssh.org/master/libssh_tutor_threads.html > Ouch. Is that requirement for libssh or for its back-ends? Other > (crypto) libraries are using system threads transparently providing > callbacks exceptionally (or even not). Openssl, libgcrypt, gnutls as > such examples. > > regards, > Nikos > > 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#ga3ebf8d6920e563f3b032e3cd5277598e>(); and link with libssh_phtreads.so. I think it's an acceptable tradeoff that will fit 99% of linux/bsd use cases. Aris
