Hi,
I permit myself to give an opinion on the subject because I just
realized today that libssh was not threadsafe in the way I though it was.
The mainline for thread safety was
"call ssh_init at the beginning of your program and libssh will be
threadsafe". Yes, except that libgcrypt and libcrypto are not
threadsafe at all (for instance in the RAND_bytes function and gcrypt's
equivalent). The only solution is to implement solutions 1 and 2 Simon
has described in his mail.
I think libssh2 falls in the same trap and has to be aware of the
threading model used by the host application since it depends on
software which is inherently not threadsafe.
My two cents,
Kr,
Aris
Daniel Stenberg a écrit :
> On Mon, 30 Aug 2010, Michel Valin wrote:
>
>> potentially dumb question/suggestion:
>>
>> why not put a mutex lock in libssh2_init() ?
>>
>> or have a libssh2_init_safe() wrapper with mutex aroud it ?
>>
>> on the down side this would force to always link with the thread library
>
> Right, libssh2 doesn't need a thread library so it doesn't check for or
> use one. Also, at least in *nix land it is also quite possible that the
> application is using its own mutex or thread library and it's hard for
> libssh2 to know which to use.
>
> Therefore, we try to document that libssh2_init is not thread safe so
> that applications that use threads can do that mutexing instead.
>
> Of course, thiis doesn't have to be like this forever, it is just how
> things work now. If you have ideas and suggestions on how to behave
> instead, please let us know.
>
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2010-08-30