Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #7265 > unrolled thread
| Started by | Jason Tackaberry <tack@urandom.ca> |
|---|---|
| First post | 2011-06-08 19:25 -0400 |
| Last post | 2011-06-08 19:25 -0400 |
| Articles | 1 — 1 participant |
Back to article view | Back to comp.lang.python
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: pthreads in C++ with embedded Python Jason Tackaberry <tack@urandom.ca> - 2011-06-08 19:25 -0400
| From | Jason Tackaberry <tack@urandom.ca> |
|---|---|
| Date | 2011-06-08 19:25 -0400 |
| Subject | Re: pthreads in C++ with embedded Python |
| Message-ID | <mailman.39.1307575632.11593.python-list@python.org> |
On 11-06-08 06:28 PM, Tom Brown wrote: > I found that PyEval_ReleaseLock() was necessary to keep the program > from hanging. The lock() and unlock() methods were used in a previous > attempt to lock/unlock the GIL. I just tried your example code and indeed it segfaults as is, but works fine for me when I comment out PyEval_ReleaseLock(). Perhaps this was just a red herring, not actually solving your deadlock problem properly? (That is, replacing one problem with another.) > I kept banging at this and finally gave up on the GIL. I used a mutex > instead. This allowed me to get rid of the Python API calls that dealt > with the GIL. It works great in the test program. I'll find out how > well it performs in the real program. I suppose this could theoretically work in your specific example, but if the Python module you're calling out to spawns threads you're screwed. :) Cheers, Jason.
Back to top | Article view | comp.lang.python
csiph-web