[Python-Dev] working with Python threads from C extension module? (original) (raw)

Bill Janssen janssen at parc.com
Sat Sep 8 01:57:40 CEST 2007

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 <janssen at parc.com> 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 testssl.py does. I'm tempted > to have the ssl module call PyEvalInitThreads(). 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

More information about the Python-Dev mailing list