> 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 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4