Thread groups -or- handling singletons in an AppDomain
-
I'm in a somewhat sticky situation. I'm developing an Explorer Bar (for IE). In my implementation, I used a few singletons for very important (core) classes which are, by design, singleton. I guess I didn't want to have to manage parent-child relations for conceivably every object I worked with, but it seems like that was a bad decision. This worked okay until I realized that new windows in IE (such as created by Ctrl-N or File->New Window) are running in the same process, and since the singleton pattern I'm using does so with a static accessor (get) property, this system fails as I believe the two instances of the Explorer Bar are running in the same AppDomain because they're running in two different threads of the same IE process. So basically, instead of having separate singletons per thread group, then end up sharing the same singleton, which is bad for Windows Forms objects. :) The kinda tricky thing is that my Explorer Bar is multi-threaded, so I can't just implement my singleton accessor using a hashtable keyed on the thread ID. If there were a way to access a thread group ID, or some sort of way to figure out which thread ID or IE window owns that particular CLR instance, that would be helpful. So any suggestions, managed or unmanaged, would be helpful. Maybe I simply need to rearchitect everything, even though now really isn't the best time for that. I'd rather be able to add a few lines into my singleton accessor (Singleton.Instance) instead. Thanks! Arun