Simon Josefsson wrote: > I've been pondering on the thread library problem for a couple of > libraries already, and the problem is Hard. The dominant solutions are: > > 0) Don't do anything and require callers to setup threading. > > Pros: > - The library is simpler and doesn't link to a thread library. > > Cons: > - Layer violation, callers needs to be aware of the crypto library > used by libssh2 and setup mutex appropriately. > > 1) Provide an APIs and let the caller set mutex hooks. > > Pros: > - The library does not have to link a thread library. > - No layering violation. > > Cons: > - It is easy to forget to make this call when you are writing > a multi-threaded program, which can lead to subtle errors.
This one can be alleviated by having the library issue a warning message at first initialization (lib_sh2_init) reminding the user that the thread-safe hook is not set. > - It is complicated to initialize the library correctly if you > have one big application that links to two separate libraries that > both in turn link to libssh2. > > 2) Hard-code the thread implementation to support during build time. > > Pros: > - Easier to use, as things happens automatically. > > Cons: > - Even non-threaded applications now link to libpthread and call > thread-related functions. > - May result in multiple libraries, one for each thread > implementation. E.g., libssh2_pthread, libssh2_gnupth, > libssh2_nptl, etc. > > There are some other alternatives, but I don't recall them now. > > I have yet to use alternative 2 successfully for a low-level shared > library. Pthreads appears to be the "winning" thread implementation on > GNU systems, so maybe it could be considered here? On my system, > libldap.so is linking to pthreads so the approach has been tested. > (However, I think there are some tricky bugs for libldap caused by this > decision.) > > Personally, my experience is that threaded programs are impossible to > maintain and keep reliable in the long run (10+ years) due to the higher > complexity. This is why I prefer approach 0 or 1, which puts the effort > on the shoulders on those that uses threading. The downside is that it > is not a responsible decision because the reality is that some things > are threaded and one has to deal with it. > > For a library like libssh2, the part that really needs mutexes today is > the RNG. Crypto libraries needs mutexes when hashing its global entropy > pool. In GnuTLS we are experimenting with using GNU Nettle (which is a > completely thread safe crypto library) and some internal randomness > functionality. I'm hoping this will work out, but it is too early to > tell. > > /Simon > _______________________________________________ > libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel -- Michel Valin Responsable, Soutien CHP | Head, HPC support CHP & Opérations des TI nationales HPC & National IT Operations Direction du dirigeant principal de l'information Chief Information Officer Branch Environnement Canada | Environment Canada 2121, N. Trans canada, Dorval, QC, CANADA H9P 1J3 [email protected] Téléphone | Telephone 514-421-4753 Télécopieur | Facsimile 514-421-4703 Gouvernement du Canada | Government of Canada Entre deux mots, il faut choisir le moindre. Always choose the shortest of two words. Paul Valéry _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
