--- In [email protected], "entropyreduction" <alancampbelllists+ya...@...> wrote: > > > Ah, I vaguely recalled that you once said that. > > Anyway, using new thread (at each object creation, right?) sounds scary to > > me. > > No, a single thread. Calls CoInitialize() as it starts, then after a bit of > housekeeping waits on single object for an event. >
Oh, that sounds better. > The code for each possible dll service gets a pointer to an object > corresponding to that service, assigns it to a pointer to a member > of type CComActionAbstract (of type that's a superclass of all classes > corresponding to action types), called. Then it raises event that unblocks > the service thread, and waits on another event that will be signalled when > that thread is done it's work. > I see, it looks complicated though. > CoUninitialize call is definitely the problem: in debugger > when I step through the one thread's code, it calls CoUninitialize in the > special case where m_pCComActionAbstract->doIt() returns false, only done by > the polymorphic version of CComActionRealeaseAll::doIt() > (called when you invoke release_all or when you unload. > > Might be a thread priority problem. > > Investigations continue. Wanna see the thread code? > I'd like to, although I'm not sure if I'm helpful here. Maybe Bruce could also take a look. Actually I'm more interested in the main-thread code as I failed to think of a reason why it didn't work. Remember? We already succeeded without a problem to call IActiveDesktop via dll.call() which just uses the main thread.
