[Cython] Segfault in PyThread_release_lock

Robert Bradshaw robertwb at math.washington.edu
Tue Aug 16 20:22:47 CEST 2011


On Tue, Aug 16, 2011 at 3:49 AM, mark florisson
<markflorisson88 at gmail.com> wrote:
> On 16 August 2011 11:39, mark florisson <markflorisson88 at gmail.com> wrote:
>> On 15 August 2011 23:33, Dag Sverre Seljebotn
>> <d.s.seljebotn at astro.uio.no> wrote:
>>> Would it be horribly expensive to generate a better runtime error, or even
>>> initialize the gil on demand? If the gil is not initialized, get the thread
>>> ID of the thread calling the callback and check against the thread entering
>>> at module initialization time...I don't know whether pythread.h has a cheap
>>> way of achieving this.
>>
>> I'm not sure how expensive PyThread_get_thread_ident(), for pthreads
>> it calls pthread_self() is. So it's either such a call for every with
>> gil, or initializing the GIL... I'll try to do some tests later today
>> and report back.
>>
>>> --
>>> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>>>
>>> Stefan Behnel <stefan_ml at behnel.de> wrote:
>>>>
>>>> Dag Sverre Seljebotn, 15.08.2011 11:54: > On 08/15/2011 11:42 AM, mark
>>>> florisson wrote: >> @Cython-dev: Do we merely want to update the docs, or do
>>>> we want to >> initialize the GIL for either case, or only for the with gil
>>>> >> functions? I'm not entirely sure what the overhead is for >>
>>>> single-threaded code, but I'd say we need to initialize it for both >>
>>>> cases. > > I'm not sure if I like magic related to having used "with gil" on
>>>> a > function signature -- it's a bit too magic and obscure. I don't really
>>>> like this either. The reason why the GIL is not being initialised by default
>>>> is that it has a runtime impact. Just because code is aware of threading
>>>> does not mean it is going to be used with threads. Especially library code
>>>> (which is a common place for using Cython) shouldn't impose such an impact
>>>> on the rest of the runtime. Stefan
>>>> ________________________________
>>>> cython-devel mailing list cython-devel at python.org
>>>> http://mail.python.org/mailman/listinfo/cython-devel
>>>
>>> _______________________________________________
>>> cython-devel mailing list
>>> cython-devel at python.org
>>> http://mail.python.org/mailman/listinfo/cython-devel
>>>
>>>
>>
>
> Ok, I attached a little script that does some computation
> (naive_convolve from the docs). This is the result:
>
> ➤ python convolve.py
> 5.61997413635
> ➤ python convolve.py --with-gil
> 5.96432781219
>
> So that mean you get approximately a 6% slowdown with the GIL
> initialized.

Thanks for the timings. Yeah, that's too high a price to pay by default.

> The alternative is that we do a check for every with gil
> in Cython code for the thread ident + PyEval_ThreadsInitialized()
> (haven't tested how much that will slow down with gil blocks, but I
> assume the difference would be nearly negligible).

You're already doing work there (by request). If there was
non-negligible overhead we could add a directive to initialize threads
at module load time and skip some of the per-withgil checks.

> So I suppose that check + abort would be the way to go?

Yep.

- Robert


More information about the cython-devel mailing list