Re: Multi-threading

[Aris Adamantiadis <aris@xxxxxxxxxxxx>]

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