On Sun, Mar 10, 2013 at 6:53 PM, Miguel Angel Ajo Pelayo
<[email protected]> 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.
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
