Well, one shouldn't be bothering with threads unless the user intends to create threads. So I think it's not kosher. Once threads are initialized, everything runs a tad slower because the GIL manipulations actually cost time (even if there are no other threads).

I think that doing it in _ssl.c might be OK; it would only happen when the user loaded that extension module. In any case, I'm going to do it that way till we figure out a better solution. The alternatives right now are (1) let OpenSSL step all over itself (and potentially other things), or (2) remove the Py_BEGIN_ALLOW_THREADS on SSL context reads and writes.

On 9/7/07, Bill Janssen wrote:

...

...

So what happens when someone loads the _ssl module, initializes the threads, and tries to use SSL? It's going to start failing again. I

Which turns out to be exactly what test_ssl.py does. I'm tempted to have the _ssl module call PyEval_InitThreads(). Would that be kosher?

The problem is the sequencing of the loading of the extension module, compared to when the user gets around to initializing threading. If we want to keep it kosher, we need a way to hook into PyEval_InitThreads() so that it will call the thread initialization routines of other dynamically loaded libraries that have already been loaded. Or a way to have Py_BEGIN_ALLOW_THREADS take into account that there may be more than one thread-dependent thing to check on. Bill