VarPyth fix for named parameters in multithreaded environment issue #125#126
VarPyth fix for named parameters in multithreaded environment issue #125#126mce2 wants to merge 1 commit intolmbelo:masterfrom
Conversation
…mbelo#125 Supposed fix to Named parameters in VarPyth not cleared between function calls lmbelo#125 issue. The patch is very inelegant, but I cannot see any side effects. As I understand, all data from named parameters is copied to a python object prior to do the actual function call, so truncation of fNamedParams should be OK at any moment.
|
I don't see how this PR resolves the issue. The problem is that fNamedParams is stored as a field of TPythonVariantType (singleton class). If multiple threads use Python Variants to make calls to Python you will still have problems, Possible Solutions:
The first option is possibly the easiest to implement but threadvars come with their own performance penalty and limitations. Why this flawed designDispInvoke calls DoProcedure and DoFunction which then use EvalPython to do the work. The inherited DispInvoke does not make use of or deal with Named arguments and it needs to be overridden as well as DoProcedure and DoFunction. They all have a fixed signature, so you cannot for example pass another parameter from DispInvoke to DoFunction and you need to have some other means of passing fNamedParams from DispInvoke to DoFunction and then to EvalPython. |
|
I am closing this and I will try to implement a more solid solultion. |
Supposed fix to Named parameters in VarPyth not cleared between function calls #125 issue. The patch is very inelegant, but I cannot see any side effects. As I understand, all data from named parameters is copied to a python object prior to do the actual function call, so truncation of fNamedParams should be OK at any moment.