'The Global xref table' ...

[Michael Meeks <michael imaginator com>]

Hi,

	It transpires that I am hitting a problem that may well become
quite common in the future. Namely this:

	xpdf and derivatives are single-pdf viewers. ie. they can only
cope with rendering a single pdf at a time; whilst they seem re-enterant
rendering that single pdf, they are not for different pdf's.

	The source of this problem is a global variable used ( once ) at
the bottom level of the message passing hierarchy and set once at the top.

	The problem is fixed in gpdf, by storing the global in the
component data structure, and restoring it / replacing it before / after
a page render. This seems to work well, however:

	This is horribly unsafe, it must be the case that no other render
operations are attempted asynchronously whilst the global variable is
switched, since this would result in unpredictable component errors.
Furthermore these would be _extremely_ difficult to debug due to their
timing critical nature.

	So... [ I'm teaching you to suck eggs here but the list is
listening:], since this may well be a common problem with Bonoboizing
various bits my solution is for now just to whack a g_mutex_lock/unlock
around any PDF opening / rendering I'm doing [ at least until someone
gives me an SMP box :-]. This will be done on a per component basis (
since I'm fairly sure they are individualy re-enterant ), and all
locking will be contained within methods since it not only kills any
chance of deadlock but makes sense.

	Does that sound at all sensible ?

		Michael.

-- 
 michael@imaginator.com  <><, Pseudo Engineer, itinerant idiot