COM Discussion Boards

7-Jun-06 2:29

Can we create COM DLL Servers which runs in a different thread than the Client? If so, could anyone point me to some websites where I may read about them.

Thanks.....

---
With best regards,
A Manchester United Fan

The Genius of a true fool is that he can mess up a foolproof plan!

Roger Stoltz7-Jun-06 11:04

7-Jun-06 11:04

TechyMaila wrote:
COM DLL Servers which runs in a different thread than the Client

Depends on what you mean by different thread than the Client's...
You can create a server from a UI thread that is not the main thread of the client, i.e. a different thread than the one handling the GUI of the client, if such exist.

If you mean that the thread should not be in the same process as the client and it has to be a DLL server, as to my knowledge the only way I can think of is using DCOM where a surrogate process is created on the server machine. Then the thread in which the server runs would of course not be in the same process as the client hence a different thread.

If it doesn't have to be a DLL then a EXE server would have the server running in a different thread since it's an out-of-process server.

Not sure if I understood your question correctly... Unsure | :~

--
Roger

It's supposed to be hard, otherwise anybody could do it!

Regarding CodeProject: "resistance is pointless; you will be assimilated"

HakunaMatada7-Jun-06 17:40

7-Jun-06 17:40

Ok, First of all, thanks for your reply.

Now, let me clear your doubts. I have a client which creates and uses a COM Server. Its an InProc Server, so I assume that it runs in the same thread which created it. Am I right? With this scenario, what happens is, if something goes wrong with the server, it crashes the client too. I do not want this to happen. Also the server makes HTTP requests over the Web, so if the Internet connection is down, then the Server Sorta hangs in the middle while trying to find the connection which in turn hangs the Client.

What would be the best solution to tackle this problem? What I had thought about is, when the client creates the Server, it should automatically be created in a different thread in the same Process so that even if something goes wrong with it, then just the thread running the server can be destroyed, which I believe would not hurt the client. Is this possible? Or, Would I have to use DCOM and run the Server in a different Process? Would a DLL Server run in a separate Process or would it have to be an Exe? The COM Server is a DLL Server.

Thanks for your time.... Smile | :)

---
With best regards,
A Manchester United Fan

The Genius of a true fool is that he can mess up a foolproof plan!

Roger Stoltz7-Jun-06 22:23

7-Jun-06 22:23

TechyMaila wrote:
Its an InProc Server, so I assume that it runs in the same thread which created it. Am I right?

Yes, it's correct.

TechyMaila wrote:
if something goes wrong with the server, it crashes the client too. I do not want this to happen

Of course one never desires to crash the client. In fact, one never desires a crash at all. Wink | ;)

What do you mean by "if something goes wrong"? Usually you should write code that handles situations when something went wrong, such as checking return values, validating pointers and so forth.
You have to watch out for call chains that can generate C++ exceptions because you cannot pass exceptions through COM interfaces. If your using classes that throws exceptions you have to catch all exceptions before returning from a call to your server. Otherwise those exceptions could be the culprit that crashes your client.
The COM way of passing exceptions is the use of ISupportErrorInfo and IErrorInfo.

TechyMaila wrote:
What would be the best solution to tackle this problem?

As I understand it you have two problems: crashes and blocking calls.
Regarding the crashes you have to write code that tackles situations that can cause a crash.
Regarding blocking calls it's difficult to advise you since you haven't described what you're trying to do in more detail. I suggest you try to use asynchronous non-blocking methods, or at least something with a timeout.
Perhaps you can find something useful in this article[^].

Hope this helps
--
Roger

It's supposed to be hard, otherwise anybody could do it!

Regarding CodeProject: "resistance is pointless; you will be assimilated"

HakunaMatada7-Jun-06 22:59

7-Jun-06 22:59

Hi Roger,

Thanks for your Reply.

If I start explaining everything, then it would be like writing an epic.. Roll eyes | :rolleyes:

so could you just guide me to any tutorials which would create the COM Server in a different Thread. I could do it from the client itself, like start a new thread and then create the COM Server but can it be such that the COM Server automatically starts in a new thread when it is created? Confused | :confused:

And you are exactly correct about the exceptions. Although I do spend a lot of time writing error/exception handling routines while coding, it just happens.. sometimes. Frown | :(

I was talking about those situations. If an unhandled exception occurs, the least that I can do is exit gracefully without hurting the client. That is what I want to do.

Thanks for you time again.

---
With best regards,
A Manchester United Fan

The Genius of a true fool is that he can mess up a foolproof plan!

Roger Stoltz8-Jun-06 0:03

8-Jun-06 0:03

TechyMaila wrote:
If I start explaining everything, then it would be like writing an epic..

Well, we don't want that.... Big Grin | :-D

TechyMaila wrote:
guide me to any tutorials

I provided you with a link to an article in my previous post. Simply click it...
I haven't read the article though, but it could contain something useful to you since seems to be about multithreaded internet connections.

TechyMaila wrote:
the COM Server automatically starts in a new thread when it is created?

This is possible, but I haven't done it myself yet.
Google for "DllSurrogate", or search MSDN and you should find how it's done.
However, I seriously doubt this is the correct way to solve your problem. You have to fix the problems of the server if it's error prone or it will be virtually useless.
If you still have problems with exceptions, try catching all att the end of the try-/catch- block with catch(...) and put an ASSERT there so you can find the root cause of the problem.
If the error is considered beyond repair, then you can alert the client by returning a suitable HRESULT. The client is then responsible for server destruction and cleanup.

--
Roger

It's supposed to be hard, otherwise anybody could do it!

Regarding CodeProject: "resistance is pointless; you will be assimilated"

HakunaMatada8-Jun-06 1:06

8-Jun-06 1:06

Hi Roger,

Thanks a lot for your input. You have indeed been very helpful.

But I have one last query to ask you. Hope you don't mind. I have to Create a Window from the COM Server. I am using WTL for creating the Window with CMainFrameTraits. Now,I would have to create a new thread within the COM Server itself and launch the Window within the new thread. That is done. Now my problem is communicating between the COM Server thread and the Window thread. How do I communicate between threads? Since the Window thread and the COM Server thread will have to work like they are on the same thread with the COM Server calling the Window's functions and vice Versa, could you enlighten me on the topic.

Thanks once again...

---
With best regards,
A Manchester United Fan

The Genius of a true fool is that he can mess up a foolproof plan!

Roger Stoltz8-Jun-06 2:12

8-Jun-06 2:12

At first I suggest you read about how to use threads, both worker threads and UI threads.
Begin with Joe Newcomer's excellent article on the subject here[^].
Since you have a window you'll also need a message pump that will be provided for you with a UI thread. Refer to Joe's article about UI threads here[^].

As for how to communicate between threads you have a lot to pick from.
The cleanest way is by posting messages between the threads. This will keep the threads asynchronous which was the general idea to begin with.
There are a lot of articles on the subject in the CodeProject article section here[^].

Regarding WTL I cannot help you personally, but Michael Dunn has written quite a few great articles about WTL here[^].

Hope this helps
--
Roger

It's supposed to be hard, otherwise anybody could do it!

Regarding CodeProject: "resistance is pointless; you will be assimilated"

HakunaMatada8-Jun-06 17:28