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 Michel.Valin_at_ec.gc.CA 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-develReceived on 2010-08-31