kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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;

public:
    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.