Prev: Visual Studio 2010 now released!
Next: Problems with a std::vector (begin and end): Different behavior debug and release version
From: Igor Tandetnik on 15 Apr 2010 17:20
Stuart Redmann <DerTopper(a)web.de> wrote:
> Well, one could argue that the COM specification offers no means to
> prevent the hosting process from terminating (at the time COM was
> designed no-one seemed to anticipate such a case), but we could do it
> by letting the InProc server launch a dummy thread per attached
> process whose sole purpose is to keep the host process alive.

I don't see how that would help. Normally, when a process decides to terminate, it will simply allow WinMain to return, at which point CRT calls ExitProcess. This will terminate all threads still running.

Further, before exiting, WinMain will likely call CoUninitialize, so even if by some miracle the process is not terminated and the DLL server survives, it will find it difficult to do any COM work.

Further still, in-proc servers often rely on their host process to run a message pump for them. If the process decides to terminate, it'll likely exist its message pump first thing.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC 1925

From: Stuart Redmann on 16 Apr 2010 03:56
On 15 Apr., 23:20, "Igor Tandetnik" <itandet...(a)mvps.org> wrote:
> Stuart Redmann <DerTop...(a)web.de> wrote:
> > Well, one could argue that the COM specification offers no means to
> > prevent the hosting process from terminating (at the time COM was
> > designed no-one seemed to anticipate such a case), but we could do it
> > by letting the InProc server launch a dummy thread per attached
> > process whose sole purpose is to keep the host process alive.
>
> I don't see how that would help. Normally, when a process decides
> to terminate, it will simply allow WinMain to return, at which point
> CRT calls ExitProcess. This will terminate all threads still running.

Gosh, I didn't realize this. For some reasons I used to believe that a
process will only terminate when the last of its threads ends.

> Further, before exiting, WinMain will likely call CoUninitialize, so
> even if by some miracle the process is not terminated and the
> DLL server survives, it will find it difficult to do any COM work.
>
> Further still, in-proc servers often rely on their host process to
> run a message pump for them. If the process decides to terminate,
> it'll likely exist its message pump first thing.

That's exactly what was going through my mind last evening when I was
about to go to sleep. However, I didn't want to wake up the children
so I decided to post this here as soon as I get in to work.
Apparently, you stand up a bit earlier.

Thank you,
Stuart
First  |  Prev  | 
Pages: 1 2
Prev: Visual Studio 2010 now released!
Next: Problems with a std::vector (begin and end): Different behavior debug and release version