Difference: RefactorForLanguages (1 vs. 3)

Revision 32015-09-01 - ChrisLiddell

Line: 1 to 1
 
META TOPICPARENT name="WebHome"

RefactorForLanguages

Line: 30 to 30
 

Comments

Added:
>
>

Tentative:

For language switching, each interpreter will hold it's own device (unlike the shared device architecture of the previous l-s attempt). The reason being that Ghostscript requires the device to be in (and use) garbage collected memory, but PCL and XPS cannot use garbage collected memory.

In addition, we plan to provide a way for each interpreter to be (optionally) closed down (preferable lazily), so there need never be more than one interpreter + device in existence at any one time.

-- Chris Liddell - 2015-09-01

 
<--/commentPlugin-->

For complex device configuration (i.e. that requires Postscript) one solution is to pass the Postscript to Ghostscript, then read the device configuration back as a C param list, which can then be sent to the actual output device for the actual language instance. \ No newline at end of file

Revision 22015-05-13 - ChrisLiddell

Line: 1 to 1
 
META TOPICPARENT name="WebHome"

RefactorForLanguages

Line: 32 to 31
 

Comments

<--/commentPlugin-->
\ No newline at end of file
Added:
>
>
For complex device configuration (i.e. that requires Postscript) one solution is to pass the Postscript to Ghostscript, then read the device configuration back as a C param list, which can then be sent to the actual output device for the actual language instance.
 \ No newline at end of file

Revision 12015-05-04 - RobinWatts

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="WebHome"

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

<--/commentPlugin-->
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright 2014 Artifex Software Inc