Another 8001010e question!

[Stuart Dootson]

Why not decouple the notifications from the Fire_XXX functions? Use an event, or similar to indicate to the COM thread that a notification has occurred (you can use some data to show what notification has occurred plus any parameters). Use a kernel wait in the COM thread to wait for the event to be signalled. When the event is signalled, call the appropriate Fire_XXX function.

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

[Kannan Ramanathan]

I thought of this...but, I am not sure how to apply this on my case..lemme explain: The server implements, lets say, "IServer" with a method "Run". I use "IServerEvents" to fire events in to connected sinks. From IServer::Run(), I call one of the library functions, which does a CreateThread() and returns. So, my Run() returns a S_OK and things are all fine so far. But, when the thread started by the library function finishes its work and wants to notify the client, it calls a callback function my server had registered with it in the start. I call Fire_XXX() in this callback, which is not working as it is in the context of another thread... Since my IServer::Run() has ended long time back, which COM context do I use?

[Stuart Dootson]

What threading model does your local server use? Is it possible that using a multithreading model might enable your original design to work?

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

[Kannan Ramanathan]

I use MTA; Still the same issue. BTW, since the thread created by library function doesn't initialize COM, in my server callback I do a CoInitializeEx to COINIT_MULTITHREADED. From this callback when I try calling Fire_XXX (in the original server object, which is passed via a context param), I still get 8001010e. Will creating a CWorkerThread/IWorkerThreadClient based thread automatically assume its parent thread COM context?

[Stuart Dootson]

I presume you have managed to successfully call one of the Fire_XXX functions in tests or something? It's not that they just don't work?

Kannan Ramanathan wrote:

Will creating a CWorkerThread/IWorkerThreadClient based thread automatically assume its parent thread COM context?

I suspect you're more likely to know than me - I think you've donw a lot more COM than me. My comfort zone is mostly in-proc servers.

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

[Kannan Ramanathan]

Thanks Stuart for the reply. Yes, Fire_xxx() events work correctly as long as they are called in the correct context. BTW, I am trying out my good old GIT solution -- only this time I am going to store the sink interfaces in GIT and store the cookie in my vector...I am currently putting together a custom IConnectionPointImpl<> to store/retrieve things properly with out breaking anything; Will update you how it goes...

[Stuart Dootson]

The other suggestion I was going to make (but didn't get around to) was to start a long-running thread and use the event idea I first proposed within that thread.

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

[Kannan Ramanathan]

Custom implementation of IConnectionPointImpl<> to make use of GIT worked like a charm! :) I'd seriously advise anyone stuck in a similar situation to try out this trick -- do let me know if you need my implementation (I think it shouldnt be a problem sharing my code, as it doesnt have any project specific details in it!) Thanks Stuart for your replies.

[Stuart Dootson]

Hint, hint - article -hint, hint. :-)

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

[Member 3480232]

Much larger than just a hint. I, for one, have been fighting problems like this for a while now and would love to look at a different view than my own for a change.:thumbsup: