[gs-bugs] [Bug 691917] Regression: Display Postscript context switching fails

bugzilla-daemon at ghostscript.com bugzilla-daemon at ghostscript.com
Mon Feb 28 20:09:47 UTC 2011


http://bugs.ghostscript.com/show_bug.cgi?id=691917

--- Comment #14 from Herbert Swan <hhwswn at gmail.com> 2011-02-28 20:09:37 UTC ---
(In reply to comment #13)
> Herbert: Thanks for your work on this. I've reopened the bug until such time as
> we commit your patch (or something like it). If we close the bug, it will
> likely be forgotten.
> 
> Your patch looks largely plausible, but I don't know the underlying code well
> enough to be sure on a quick examination - in particular I'd like to understand
> the motivation behind the changes to the scheduler table changes.
> 
> Are you happy to assign copyright in these changes to Artifex? As well as the
> GNU GPL release we license Ghostscript under the Artifex commercial license, so
> we need to have clear ownership of code. A note here saying you are happy
> should suffice, I believe. Many thanks.
> 
> Probably best for someone with more experience in this area to look at it, so
> passing it back to Alex.
> 
> Alex: If you're too busy, please feel free to pass the bug back to me. Thanks.

Every context must have an index of type ulong associated with it.  You need
this index identifier to reference the context, notify it, join it or detach
it.  This index must be a unique gs_id, allocated by gs_next_ids.  In the
distant past, gs_ids weren't used very often, so the number never got very
high.  So when Peter Deutsch wrote the original version of zcontext.c, it was
acceptable to take the identifier returned from gs_next_id, modulo the number
of context slots available in the scheduler (19), to get the slot number of the
new context.  Now, however, many things use gs_ids so the numbers rise into the
hundreds and even thousands.  Even if there is only one other context active,
there is still a 1:19 chance that its slot number will be overwritten the next
time a new context is created, with no safeguards in place to keep that from
happening.  This is why I thought it necessary to change the slot allocation
scheme from a quasi-random one to a sequential block.

Yes, I am willing to transfer the ownership of these proposed patches to
Artifex.  I hope you find them useful.

-- 
Configure bugmail: http://bugs.ghostscript.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.


More information about the gs-bugs mailing list