[Cython] Segfault in PyThread_release_lock

[mark florisson]

On 16 August 2011 07:52, Robert Bradshaw <robertwb at math.washington.edu> wrote:
> 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?

It is not possible to do it on demand, this has to happen in the main
thread, as the main thread needs to acquire the GIL (and release it
after so many ticks). As for the runtime impact, I'm not convinced
it's so big, I think we should test this. What we could do is abort
with a useful message if the GIL is not initialized in a non-main
thread, perhaps with a link to some documentation shedding some light
on the matter.

>> 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
>>
>>
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>