Showing content from http://mail.python.org/pipermail/python-dev/attachments/20070908/5d3a01f6/attachment.htm below:
On 08/09/2007, <b class="gmail_sendername">Bill Janssen</b> <<a href="mailto:janssen@parc.com">janssen@parc.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> Be convoluted yourself and do this:<br>><br>> #define PySSL_BEGIN_ALLOW_THREADS { if (_ssl_locks) { Py_BEGIN_ALLOW_THREADS<br>> #define PySSL_END_ALLOW_THREADS Py_END_ALLOW_THREADS } }<br>><br>> (Untested, but I think it should work.)
<br><br>Yes, that had occurred to me. We want the code inside the braces<br>still to run if the locks aren't held, so something more like<br><br> #define PySSL_BEGIN_ALLOW_THREADS { \<br> PyThreadState *_save; \
<br> if (_ssl_locks_count>0) {_save = PyEval_SaveThread();}<br> #define PySSL_BLOCK_THREADS if (_ssl_locks_count>0){PyEval_RestoreThread(_save)};<br> #define PySSL_UNBLOCK_THREADS if (_ssl_locks_count>0){_save = PyEval_SaveThread()};
<br> #define PySSL_END_ALLOW_THREADS if (_ssl_locks_count>0){PyEval_RestoreThread(_save);} \<br> }<br><br>would do the trick. Unfortunately, this doesn't deal with the macro<br>behaviour. The user has "turned on" threading; they expect reads and
<br>writes to yield the GIL so that other threads can make progress. But<br>the fact that threading has been "turned on" after the SSL module has<br>been initialized, means that threads don't work inside the SSL code.
<br>So the user's understanding of the system will be broken.<br><br>No, I don't see any good way to fix this except to add a callback<br>chain inside PyThread_init_thread, which is run down when threads are<br>initialized. Any module which needs to set up threads registers itself
<br>on that chain, and gets called as part of PyThread_init_thread. But<br>I'm far from the smartest person on this list :-), so perhaps someone<br>else will see a good solution.</blockquote><div><br>I think this is a helpful additional tool to solve threading problems. Doesn't solve everything, but it certainly helps :-)
<br><br>For instance, one thing it doesn't solve is when a library being wrapped can be initialized with multithreading support, but only allows such initialization as a very first API call; you can't initialize threading at any arbitrary time during application runtime. Unfortunately I don't think there is any sane way to fix this problem :-(
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">This has got to be a problem with other extension modules linked to<br>libraries which have their own threading abstractions.
</blockquote><div><br>Yes.<br><br>Another problem is that python extensions may not wish to incur performance penalty of python threading calls. For instance, pyorbit has these macros:<br><br>#define pyorbit_gil_state_ensure() (PyEval_ThreadsInitialized()? (PyGILState_Ensure()) : 0)
<br><br>#define pyorbit_gil_state_release(state) G_STMT_START { \<br> if (PyEval_ThreadsInitialized()) \<br> PyGILState_Release(state); \<br> } G_STMT_END<br><br>#define pyorbit_begin_allow_threads \
<br> G_STMT_START { \<br> PyThreadState *_save = NULL; \<br> if (PyEval_ThreadsInitialized()) \<br> _save = PyEval_SaveThread();<br><br>#define pyorbit_end_allow_threads \
<br> if (PyEval_ThreadsInitialized()) \<br> PyEval_RestoreThread(_save); \<br> } G_STMT_END<br><br>They all call PyEval_ThreadsInitialized() before doing anything thread related to save some performance. The other reason to do it this way is that the Python API calls themselves abort if they are called with threading not initialized. It would be nice the upstream python GIL macros were more like pyorbit and became no-ops when threading is not enabled.
<br><br></div></div>-- <br>Gustavo J. A. M. Carneiro<br>INESC Porto, Telecommunications and Multimedia Unit<br>"The universe is always one step beyond logic." -- Frank Herbert
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