Eclipse Internal Architecture/Design Question: How singleton plug-ins are used to manage multiple launches/environments?

I am concerned about the way plug-ins are supposed to behave in managing multiple launches/environments. As most plug-ins in Eclipse are singleton, it seems that a Plug-in is instantiated once and after that it is used for all launches/environments. From this perspective it seems that a plug-in just adds n开发者_运维问答ecessary components/functionality to Eclipse and provides static methods. However, it has to keep data/behavior for each launch/environment separated in some way. Here is my question: Is there any standard approach (e.g., a set of predefined classes/interfaces) for this data/behavior separation or, does every plug-in manages it in its own way?

I decided to investigate a little bit. I looked at Eclipse Debug Package. This package is a rich collection of plug-ins working together to provide services for multiple launches/environments debugging.

In this package, a launch state is encapsulated in objects instantiated from Launch and DebugTarget. However the access to these data is not limited to any object or thread. The design is mainly based on event dispatchers and listeners. It provides flexibility for adding new features, but less control over data accesses and state transitions. In particular, developers have to be careful about concurrency issues.