Hi all,
I'm writing a dll plugin for a program (app#1) that uses c-style function calls of my dll. Each time app#1 loads and calls one of my functions, my dll must communicate with yet ANOTHER external application (app#2), this time via a window message loop with WM_COPYDATA (I don't have a choice here).

I'd like the put all the junk dealing with this processing and communication in a separate class so the exported dll functions are cleaner. This class would by called like myclass:rocess(data) or myclass::instance()->process(data), etc, send and receive with app#2, then callback a function in my dll with the results, then the dll will work with app#1 again. That's all fine and dandy, but I'm unsure how to do it.

I was originally thinking that since all the functions in my dll will require the same class, a singleton might suffice, but once I tried setting up a separate thread for a hidden window creation along with a message loop to receive the WM_COPYDATA response from app#2, the singleton instance was never destroyed when the dll unloaded and everything crashed.

I played around with this pattern for a while, but then I started wondering if this is even the correct way to go about it. App#1 might call my dll in rapid succession, and I'd need to quickly send this to app#2 and receive it's responses in the order app#1 wants them.

Does this bring to mind any design patterns that would work for these circumstances? Maybe some code? Or, if you think the singleton is the best way, any tips on multithreaded singletons that aren't messy?