[Pyrex] [Cython-dev] Callbacks from threads and PyGILState_Ensure/PyGILState_Release

[Greg Ewing]

Ulisses Furquim wrote:
> Can we really check if what the programmer does with the GIL makes
> sense all the times?

No, but I think most of the time we can check whether
what he says he thinks he is doing is self-consistent.

> Besides the two external declarations, the programmer still had to
> call "do_something_heavy" under "without GIL".

Yes, the programmer has to realise that it is appropriate
to release the GIL in the first place. But if he doesn't
do that, it won't lead to a crash.

I'm not trying to make Pyrex decide for itself when
releasing the GIL would be a good idea -- just trying to
arrange things so that, if the programmer does decide
to do so, he's least likely to shoot himself in the foot
as a result.

> you better call some blocking IO function or
> some main loop entering function (like g_main_loop_run or other
> equivalent) under "without GIL" if you want your multi-threaded
> programs to work reliably.

> Reading all this I thought we might just want something simpler to
> start with

There will certainly be something simpler to start with.
I just want to make the simpler thing forward-compatible
with something more elaborate later.

>     cdef void my_callback(void *data):
>       with GIL:
>         print "Called back!"

Unfortunately, that doesn't quite work, because Pyrex
generates increfs for args and locals before getting to
the "with GIL:" statement. That's why the whole idea of
having something in the function header got started.

-- 
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | Carpe post meridiem!          	  |
Christchurch, New Zealand	   | (I'm not a morning person.)          |
greg.ewing at canterbury.ac.nz	   +--------------------------------------+