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.
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
