kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On Sun, Mar 10, 2013 at 6:53 PM, Miguel Angel Ajo Pelayo
<miguelangel@xxxxxxx> wrote:
> I'm starting to remember, yes,
>
> scripting/python_scripting.h:#define PY_BLOCK_THREADS(name)    wxPyBlock_t name = wxPyBeginBlockThreads()
> scripting/python_scripting.h:#define PY_BLOCK_THREADS(name)
>
>
> We needed that blocking, because, when using wxpython, If I'm not wrong (and I use to be more often than I like),
> when using wxpython, the event loop is handled from python itself, that means that at any time we call
> most probably we're making a concurrent call to python's VM.
>
> I think that you not only fixed a bug for windows, but for a broader audience, only that other audiences where
> not "lucky" enough to get the into the concurrence problems,
>
> I misplaced the wxPyBeginBlockThreads, that also needed to protect other calls to python runtimes….
>
> but ok, that's a start, I must re-investigate how that wxPython thing worked….
>
> thanks again Brian!! :)

Now at my computer, instead of phone, so I can do more digging.
I was thinking the lock used thread local storage, and it was not
being setup correctly at dll initialization time.

It looks like Miguel is right and Brian's patch is a step in the right
direction:

    http://docs.python.org/2/c-api/init.html#thread-state-and-the-global-interpreter-lock

But I don't think the patch goes far enough, and when using lock's
I've had good results with C++ wrapper classes to get the unlocking
right.

For locks like this I like to use C++'s constructor and destructor to
ensure that the unlock is called, even if there is an exception or a
programmer bug, and that a well defined scope is in play.

I will commit something in a few minutes.

Brian if you can test that please, then you are da man.