RefactorForLanguages

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