Bob Ippolito [EMAIL PROTECTED] writes:
Is there a good reason to *not* call PyEval_InitThreads when using a
threaded Python?
Well, it depends how expensive ones OS's locking primitives are, I
think. There were some numbers posted to the twisted list recently
that showed it didn't make a whole
On Apr 10, 2005, at 11:22 AM, Michael Hudson wrote:
Bob Ippolito [EMAIL PROTECTED] writes:
Is there a good reason to *not* call PyEval_InitThreads when using a
threaded Python?
Well, it depends how expensive ones OS's locking primitives are, I
think. There were some numbers posted to the twisted
James Y Knight [EMAIL PROTECTED] writes:
On Apr 10, 2005, at 11:22 AM, Michael Hudson wrote:
Bob Ippolito [EMAIL PROTECTED] writes:
Is there a good reason to *not* call PyEval_InitThreads when using a
threaded Python?
Well, it depends how expensive ones OS's locking primitives are, I
On Apr 10, 2005, at 2:48 PM, Michael Hudson wrote:
James Y Knight [EMAIL PROTECTED] writes:
On Apr 10, 2005, at 11:22 AM, Michael Hudson wrote:
Bob Ippolito [EMAIL PROTECTED] writes:
Is there a good reason to *not* call PyEval_InitThreads when using a
threaded Python?
Well, it depends how
Bob Ippolito [EMAIL PROTECTED] writes:
On Apr 10, 2005, at 2:48 PM, Michael Hudson wrote:
James Y Knight [EMAIL PROTECTED] writes:
Here's the numbers. It looks like something changed between python 2.2
and 2.3 that made calling PyEval_InitThreads a lot less expensive. So,
it doesn't seem
On Apr 10, 2005, at 4:08 PM, Michael Hudson wrote:
Bob Ippolito [EMAIL PROTECTED] writes:
On Apr 10, 2005, at 2:48 PM, Michael Hudson wrote:
James Y Knight [EMAIL PROTECTED] writes:
Here's the numbers. It looks like something changed between python
2.2
and 2.3 that made calling PyEval_InitThreads
On Apr 9, 2005, at 11:15 AM, Michael Hudson wrote:
Gregory P. Smith [EMAIL PROTECTED] writes:
Under Limitations and Exclusions it specifically disowns
responsibility for worrying about whether Py_Initialize() and
PyEval_InitThreads() have been called:
[snip quote]
This suggests that I should call
Under Limitations and Exclusions it specifically disowns
responsibility for worrying about whether Py_Initialize() and
PyEval_InitThreads() have been called:
[snip quote]
This suggests that I should call PyEval_InitThreads() in
initreadline(), which seems daft.
fwiw, Modules/_bsddb.c
Michael Hudson wrote:
Option 1) Call PyEval_ThreadsInitialized() in PyGilState_Release().
Non-invasive, but bleh.
Tim rejected this option back when PyEval_ThreadsInitialized() was added to the
API [1]. Gustavo was having a similar problem with pygtk, and the end result was
to add the
Nick Coghlan [EMAIL PROTECTED] writes:
Michael Hudson wrote:
Option 1) Call PyEval_ThreadsInitialized() in PyGilState_Release().
Non-invasive, but bleh.
Tim rejected this option back when PyEval_ThreadsInitialized() was
added to the API [1].
Well, not really. The patch that was rejected
[Michael Hudson]
...
Point the first is that I really think this is a bug in the GilState
APIs: the readline API isn't inherently multi-threaded and so it would
be insane to call PyEval_InitThreads() in initreadline, yet it has to
cope with being called in a multithreaded situation. If you
Tim Peters [EMAIL PROTECTED] writes:
[Michael Hudson]
...
Point the first is that I really think this is a bug in the GilState
APIs: the readline API isn't inherently multi-threaded and so it would
be insane to call PyEval_InitThreads() in initreadline, yet it has to
cope with being called
12 matches
Mail list logo
