Dennis Lee Bieber writes:
> It's been tried -- but the non-GIL implementations tend to be
> slower at everything else.
Has Micropython been compared? CPython needs the GIL because of its
frequent twiddling of reference counts. Without the GIL, multi-threaded
CPython would have to acquire
On Friday, May 13, 2016 at 7:12:33 PM UTC+2, MRAB wrote:
> Every PyGILState_Ensure call must be matched with a PyGILState_Release
> call. The way it's currently written, it won't call PyGILState_Release
> if ret is NULL.
Yeah, that's tiny bug, however it is not the main problem...
> However, I
On 2016-05-13 17:22, Øystein Schønning-Johansen wrote:
On Friday, May 13, 2016 at 2:04:53 AM UTC+2, Sturla Molden wrote:
You must own the GIL before you can safely use the Python C API, object
creation and refcounting in particular. Use the "Simplified GIL API" to
grab the GIL and release it whe
On Friday, May 13, 2016 at 2:04:53 AM UTC+2, Sturla Molden wrote:
> You must own the GIL before you can safely use the Python C API, object
> creation and refcounting in particular. Use the "Simplified GIL API" to
> grab the GIL and release it when you are done.
I've now read about the GIL and it
wrote:
> Second and most important question: When I run this code it sometimes
> segementation faults, and sometimes some threads run normal and some
> other threads says "Cannot call 'do_multiply'". Sometimes I get the
> message: Fatal Python error: GC object already tracked. And some times it
>
Hi,
I have a framework written in C and I need to call Python from that framework.
I have written the code, and it runs fine, however when I recompile with OpenMP
enabled, I get segmentation faults and some times an error message:
Fatal Python error: GC object already tracked
I'm able to reco
