[Cython] Segfault in PyThread_release_lock

Robert Bradshaw robertwb at math.washington.edu
Tue Aug 16 07:52:33 CEST 2011


On Mon, Aug 15, 2011 at 2:33 PM, 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.

This seems reasonable. In particular, it wouldn't have an impact on
code not referencing the GIL. This wouldn't solve the issue of making
sure the threads have been registered with the interpreter though,
would it?

> 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
>
>


More information about the cython-devel mailing list