← Back to team overview

kicad-developers team mailing list archive

Re: Scripting on Windows Fix

 

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.


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

PyGILState_STATE gstate;   
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);


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.




Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo

On 11/03/2013, at 09:12, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:

>> I will commit something in a few minutes.
>> 
>> Brian if you can test that please, then you are da man.
> 
> Its very late here, it was rushed, but I checked in something that might help.
> 
> in rev 3994.


Follow ups

References