kicad-developers team mailing list archive
Mailing list archive
Re: Scripting on Windows Fix
On Sun, Mar 10, 2013 at 6:53 PM, Miguel Angel Ajo Pelayo
> 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
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
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.