Do NOT touch crypto code.

No, I'm not coding any crypto algorithms. Even following discussions about coding them, like gnutls, nettle, and openssl mailing lists, is hard. But just to demonstrate the complexity of coding crypto algorithms, think of side-channel attacks. I quote here from a mailing list on nettle:

Let me first explain what I mean when I talk about a "side-channel
silent" function. That means that if we call the function with operands
which are of the same size, but otherwise different, the function should
execute exactly the same sequence of instructions in both cases, and
access memory in exactly the same pattern.

If one then assumes that the underlying machine instructions have data
independent timing (true for most current cpus), we leak no side
information from timing or cache behaviour. We may still leak
information through power analysis, if, e.g., executing a multiplication
instructions consumes different amount of energy depending on the input
bit patterns.

-- Niels Möller

What does that mean? It means "Do NOT touch crypto code". Unless you understand the implications. And there are too many implications in too many aspects, that laymen like you and me do not understand. I mean, can you even imagine that your code could be susceptible to power analysis? I mean, yes, in algorithms you've been taught that a multiplication is "costlier" than addition, and if you've studied transistors and digital logic and algorithm analysis, you might begin to understand why, because more transistors are needed for multiplication (I'm guessing here), but to think that that cost involves differences in power usage! Well of course, but then to think that that difference in power usage could be used to analyse the number of multiplications used by your code, and hence begin to backtrack the input of your functions! Yeowza. So hey, lesson of the day: "Do NOT touch crypto code".

OpenSSL, cURL, and multithreading.

OpenSSL is one of the most widely used crypto library. Supports many digest and cipher algorithms, many types of protocols, very light and extremely optimized for many platforms (take a look at the arm assembly or x86_64 assembly codes for different algorithms.. gives you a sense of the awesome work put into it by experienced people through the years), and yet, out of the box, it is not thread-safe.

Couple of points to note here:
- This does not mean that OpenSSL cannot be used in a thread-safe way. It can be, but a little work has to be put in.
- Related links: http://horstr.blogspot.in/2008/04/on-libcurl-openssl-and-thread-safety.html,
http://curl.haxx.se/libcurl/c/threaded-ssl.html, http://stackoverflow.com/questions/3281373/segmentation-fault-in-libcurl-multithreaded.
- cURL is a URL handler, like wget, and it fetches the contents of urls. For HTTPS connections, you can make curl use either OpenSSL, or GnuTLS, or other supported implementations of SSL. OpenSSL is default.
- When using curl in multi mode, you can create several easy handlers (like one for each url), and attach them  to a single multihandle, so as to give commands to the multi handle which it internally performs on each of the urls. Since OpenSSL is not threadsafe by default, this multi handle usage of curl can cause rare random crashes.
- To avoid all these, OpenSSL provides callback mechanism to set your own locking functions (like simple pthread mutexes, or your own mutexes/locks if you prefer). This will enable multiple parallel initializations and cleanups without causing a hitch.

Now the question arises, who sets these callback functions? Curl certainly doesn't set it, and shouldn't, in my opinion as it should remain light, portable, and shouldn't define its own constraints. The final app can always set its own callbacks. Imagine, then, if multiple apps are running as threads in a single process... like maybe in a browser/platform or something... If each of the apps set their own callbacks, there is the possibility that these locks are not mutually interoperable. So shouldn't the browser/platform set its own callbacks? Should they or shouldn't they be overrideable by the apps' callbacks? ugh. I've never liked mutexes and semaphores. too messy :(