Hi Bruce, Problem isn't really with unload.
For reasons that are entirely unclear to me, I can't do most things to COM objects in com dll unless (a) they're done on a thread of dll's creation (b) the thread proc calls OleInitialise() when it starts running. All requests for any activity affecting COM objects do the equivalent of setting flags and data structures to indicate what needs doing, then signal the thread to run and wait for it to signal back. (since I like C++, I initialise a singleton object which knows how to do the activity required, set a pointer to that object which the thread know how to use, but same thing). As now written, unload and release_all cause both set things up so that the thread proc releases all COM objects stored by calls to com services, signals its finished and terminates. It used to also call OleUnInitialise(); But doesn't matter whether this sequence of events happens because of call to unload or release_all, result is same: the thread proc stalls on call to OleUnInitialise(). I could I suppose leave the thread in place when calling release_all, so thread would exist until plugin was unloaded. --- In [email protected], "brucexs" <bswit...@...> wrote: > > --- In [email protected], "entropyreduction" > <alancampbelllists+yahoo@> wrote: > > > > Right, then problem has gotta be something I changed in com dll. > I think you may have answered this before, but is there even a need to > support unload? Maybe just need to some kind of interface to "free any com > objects that have references on them (that were created in the plugin). In > fact, you could just do that and only that in the unload. > The memory for the com plugin itself has got to be trivial...
