← Back to team overview

kicad-developers team mailing list archive

Re: Scripting on Windows Fix


On 03/11/2013 03:50 AM, Miguel Angel Ajo Pelayo wrote:
> Thanks dick, 
> I think the class constructor it's a very clean/smart  solution (set
> and forget at block level).
> I wonder if the wx/python , takes care of double-locks from the same
> thread.

Good question, can you find out please?
If not, some protection against this would be prudent.

> Totally right, was thinking the same, just that we don't have
> concurrency now without wxpython running on top, doesn't mean that
> this won't happen at any time:
> 0
> public:
> 51
>     // @todo: this is wrong, python docs clearly say we need the GIL,
> 52
>     // irrespective of wxPython.
> At that point without wx I think we should do this:     

Right, why put a time bomb in your jock strap?

> PyGILState_STATEgstate;   
> gstate = PyGILState_Ensure();
> /* Perform Python actions here. */
> result = CallSomeFunction();
> /* evaluate result or handle exception */
> /* Release the thread. No Python API allowed beyond this point. */
> PyGILState_Release(gstate);

>From reading the docs, that should do it.  We put the return value of
PyGILState_Ensure() into an instance variable within PyLOCK:

class PyLOCK
    PyGILState gil_state;

    PyLOCK()      { gil_state = PyGILState_Ensure(); }
    ~PyLOCK()     { PyGILState_Release( gil_state ); }

If you can test that on some platform, and it works, it will likely
work on all.  I'm in meetings rest of today.  Thanks for the suggestion.

> About the coding style fixes, I must reread the coding style policy,
> and use uncrustify + diff before any push, it seems that
> at that time I was yet unaware of some coding policies.

Follow ups