Single Instance of Server for multiple clients

[muscicapa]

I want to maintain a single remote server for all client requests without the hassle of too much multi threading. The idea is for a kind of Chat server - The single server maintains a list of all the client Sink pointers. But every time a client does a CoCreateInstanceEx, a new server is started. How do I make an already running server respond to the newer client requests ?
- muscicapa

[chris law]

in ATL there's something like ClassFactorySingleton, that only creates one instance of your COM object, other requests receive interface on that object.

(you could use static data too...)
hope this helps

chrislaw

[muscicapa]

Thanks, it works fine, but is there a possibility that some client request can be lost if the server is busy during that time ? If so can that be avoided by putting my time consuming function in another thread(worker) ?

[chris law]

Hi
Now i'm on thin ice, but anyway, i think that COM port requests are already handled in a different thread than your objects executed thread. If a request comes in, depending on your objects threading model, the according functions are called directly or synchronized through window messages.
I think that you can make your object react faster if you use a multithreaded apartment (in order to allow multiple threads to call your methods at the _same_ time. If you like to pass control back to the calling thread (app) sooner than the time needed for your method to finish, you can (in the interface method) start (or resume) a worker thread that does the actual work. Return results as events (through connection points although I heard rumours that this design will be changed with next generation of COM -> COM+).
I have to warn you also that firing events from different threads got me into troubles with VB (I had to synchronize the event firing through windows messages into the main object thread (the thread that gets started with first InitInstance call)...

I hope this gives you some idea what you want to try (i like to discuss further aspects but have not much more experience than you ;-)

chrislaw