Why is it a bad idea to use “Global” variables, that is Public (and private) variables at module level ?
All variables at module level are thread specific. Each new thread starts get a new fresh & uninitialized copy of such variables. I’ve verified that all the activities that are born from the same object context always run in the same apartment (I checked the thread id) as the object context had thread affinity. What i mean is this: suppose you have an mts object that has a method that returns the thread id and then calls set complete. Each call to the method starts a new activity but the thread id returned is always the same. This could sound tempting to store some state across activity boundaries but since the number of thread available for a package is limited (100 by default) you would end up having, under heavy stress, different activities sharing the same apartment and then the same public .bas variables. with unpredictable results.
Related Questions
- Obamas idea of a public insurance plan to compete with private ones is meeting resistance. Will the alternative of health insurance cooperatives suffice?
- Is there some difference between the data protection level or encryption strength of the Private and Public levels?
- Why is it a bad idea to use "Global" variables, that is Public (and private) variables at module level ?
