I need multiple instances of the engine.
Printable View
I need multiple instances of the engine.
If the engine itself isn't thread safe, then you aren't going to be able to use multiple instances of it from different threads within the same process. That's it - end of story.Quote:
Originally Posted by Dawoodoz
What you can do is to wrap the engine inside an out of proc COM server (.exe server) and configure the COM server to create a new process for each engine instance.
Then have your ActiveX control create an instance of the engine via the COM server as appropriate. Not real efficient, but doable.
Of course, a better approach would be to make the engine threadsafe.
I have done that and it is safe when the instances don't have any memory in common. The problem with thread safety occur when the user make two calls to the same instance.Quote:
Originally Posted by Arjay
You have done what? If multiple instances of the engine don't work 100% of the time, then the engine isn't thread safe. If the 'memory in common' isn't within the engine, then synchronize access to the memory.Quote:
Originally Posted by Dawoodoz
Btw, in addition to accessing the engine with the COM class instance, are you accessing any global variables?
Multiple instances of the engine do work 100% of the time as long as the user don't make 2 calls to the same instance. I use ActiveX with no data outside of the class since sharing data between them would be stupid.
So separate instances of the engine work okay, but each engine instance isn't thread safe. Okay, that brings the question:
When do you create an engine instance? Do you create a new engine for each instance of CDFPGECtrl?
The engine is created when the control is created but a starting call is needed before the engine is running and accepting input.
So when a control is created it creates a new engine instance? I'm asking because your term 'the engine' may imply only one engine instance (shared between multiple control instances).Quote:
Originally Posted by Dawoodoz
Yes, they share absolutely nothing like a regular ActiveX component.
Put some TRACE statements in your code and spew the output to a debug window. In the TRACE statement, record the method name and the thread Id of the current thread.
That will give you an idea of if things are working as you expect. From what you are describing it sounds like an ActiveX control instance is getting shared between threads.
Yes, that is what I try to protect it from because my engine should be foolproof for beginners.
What could help is if you returned rich error information from your COM methods.Quote:
Originally Posted by Dawoodoz
Why not use the COM approach and return an HRESULT
Code:HRESULT CDFPGECtrl::Camera_RenderScene(...);
Checking for return values all the time makes the engine less user friendly and I can't have multiple return values. I have a delayed message system that puts a message in a queue when an error occurs so that it is threadsafe for Visual Basic 6 but not any multicore language.Quote:
Originally Posted by Arjay
Why not do both? Provide return values for those developers that want to use them and give the option of the error messaging.
Experience developers probably want to know that a call has succeeded or not at the time of making the call.