On Thu, 27 Jun 2013, David Malcolm wrote: > I want to focus on "removal of global state", and I want that to be > separate from "cleanups of internal APIs".
Whereas I'm thinking of global state as being a symptom of a problem - messy interfaces that have accreted over time - rather than the problem in itself. And moving things into "universe" allows a proof-of-concept of a shared library build (much like Joern's multi-target patches with namespaces three years ago provided a proof-of-concept of a multi-target build) without really addressing the real problem (basically, I think of state in "universe" as effectively being global state, and moving state into something passed down to the places needing it - only the relevant bits of state, not a whole universe pointer if there's a smaller logical unit - rather than just accessed through TLS, as being the point where global state is *really* eliminated). Now, the bulk conversion to universes seems a lot more maintainable than Joern's multi-target patches, and a lot more plausibly an incremental step to a proper fix, and so a lot more reasonable to go in as an incremental step, but I'd still think of it as one of the infamous partial transitions in the absence of a reason to believe, for each formerly-global object being accessed via the universe (or some other piece of context), that it's being accessed via the right piece of context being passed down to functions that need it, rather than from the global universe for something that doesn't need to be. As for accessing globals directly versus via APIs: yes, I suppose you do still have an access to a global class instance in each place you formerly had a global variable (that's now a member of that class), so by itself such a conversion to a better API doesn't reduce the number of global variable accesses, just improves the interface in other ways - and it's the changes to pass a pointer to an instance around that reduce the global state usage. In the case of dump files, pass-local state may be a better place than the universe to keep the instance - it is after all passes.c that calls dump_start / dump_finish. (Indeed, it would arguably be an improvement, in cases where an API uses global state completely implicitly as opposed to via a class instance that contains that state, to pull out that global state to the call sites, reflecting that eventually those call sites should be passing in proper non-global values. For example, converting those diagnostic function uses that implicitly use input_location to use it explicitly instead - each should eventually move to an explicit location that isn't input_location. Implicit use of global_dc matters rather less and it seems reasonable enough for that context to continue to come from the universe in many cases. Cf. how a couple of years ago I made a lot more option-handling code pass around struct gcc_options *, location_t and diagnostic_context * values, rather than directly using the globals - although at some point, a global value tends to get passed into these functions.) (Similarly, for target macro to hook conversions (a) I consider a function in targhooks.c that uses the target macro just to be an interim step and a macro only really to be addressed once all the definitions in different targets have been converted to define functions and the macro has been poisoned, and (b) for each such conversion we at least consider what the hook ought to look like rather than presuming a direct conversion of the macro semantics, one macro to one hook, is appropriate.) -- Joseph S. Myers jos...@codesourcery.com
