We want to refactor various bits of the
GhostPDL internals so as to make a Language Switch build easier.
This file is for recording thoughts on this goal.
Currently, we have the following structures:
- gs_lib_ctx_t
- The top level 'library context'. Just one of these per instance of GhostPDL. Stores global settings, such as stdio functions, and the icc engine. Contains a pointer to the 'top_of_system'. In gs this is a pointer to gs_main_instance, in 'pl' builds, a pointer to pl_universe. Also contains details of the gs_memory_t used to allocate it. Also currently contains various gs interpreter specifics.
- gs_main_instance
- The details of the gs interpreter state. Contains a pointer to the gs_memory_t that allocated it.
- gs_memory_t
- Details of various memory allocators, together with a pointer to the gs_lib_ctx.
I propose to rejig these very slightly as follows.
- gs_lib_ctx_t
- Stays as a the top level 'library_context'. Still just one of these per instance of GhostPDL. Stores global settings, such as stdio functions, and the icc engine. Contains a pointer to the 'topmost language'. Also contains details of the gs_memory_t used to allocate it, which is the topmost allocator in the system. All other allocators are derived from that. The gs interpreter specifics should be moved into gs_main_instance.
- gs_main_instance
- Think of this as 'gs_language_instance' (even though we may not actually rename it to prevent API breakages). A gs_main_instance will contain a vtable of function pointers used to implement the language API, a gs_memory_t, a pointer to the lib_ctx, and a (possibly NULL) pointer to its parent language. Each language implementation will derive a new struct from this and bundle their own specifics within that; so for example Ghostscript would have a structure 'gs_main_instance_gs' that contained the standard gs_main_instance information, plus their own specifics. The language switch build is thus a language that contains various sublanguage pointers within it.
- gs_memory_t
- Details of various memory allocators, together with a pointer to the language instance (a gs_main_instance) to which it applies.
Every language instance gets its own gs_memory_t.
At any given point during execution, we typically have just a gs_memory_t pointer. In the current code we can go from this to the lib_ctx, and then to the main_instance if required. In the new scheme of things we can go from gs_memory_t to the language instance to which it applies. From there we can go either to the lib_ctx, or to the parent instance.
--
Robin Watts - 2015-05-04
Comments