PDA

View Full Version : Should I copy action/event args in gir_xxx critical section



gbumgard
April 24th, 2006, 04:33 PM
In gir_event and gir_conditional_test, I have been executing my action code within the critical section, as opposed to "planning" them and executing them outside of the lock. I have made no attempt to minimize the time spent holding the lock.

Should I instead copy the Action/Event args I need withing the critical section and then execute my actions/tests, or does it make a difference? I assume the critical section is required to support multithread access to the girder tree so I would want to minimize time spent holding the lock.

Ron
April 24th, 2006, 05:43 PM
That is correct. What are you doing during the lock. Any idea how much time?

gbumgard
April 24th, 2006, 09:04 PM
Two or three calls on SAPI objects, mostly calls to change COM object states. I haven't been doing any COM object creation calls (except in the Plugin config).

-g.b.

Ron
April 24th, 2006, 09:23 PM
Well as long as the time is small like 1/4 second max and the user doesn't run a bunch of these within a short time it should be fine. Make sure all calls to your com object are on the same thread. Girder tries to do this but it might not be everywhere. So if you are experiencing weird stuff,.. look at this.

gbumgard
April 25th, 2006, 12:54 AM
Is girder always calling gir_event in the same thread?

Ron
April 25th, 2006, 10:27 AM
yes it is.

gbumgard
April 25th, 2006, 01:28 PM
At the moment, I do everything within the calling thread. I'm using callbacks for the SAPI events. I can use callbacks because the girder thread apparently has a message pump.

My original girder-3 SAPI implementation was multithreaded. It was implemented using ATL and was much more complicated than my new implementation. I no longer need to worry about typelibs, marshalled COM interfaces and multithread synchronization on the event sinks.

Because I'm running in the same apartment as the girder calling thread, I don't think users will be able to call functions exposed by the plugin from new threads created in lua.

Would you agree?

Promixis
April 25th, 2006, 02:21 PM
lua offers the function

gir.RunCodeOnMainThread

which might solve this problem... lets see what Ron says ;)

Ron
April 25th, 2006, 03:31 PM
You could do that indeed. Things become quite tricky though.