Re: Multi-threading

[Aris Adamantiadis <aris@xxxxxxxxxxxx>]

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