[reportlab-users] CPU Loop in graphics caused by uppercase font filename

[Robin Becker]

Roger wrote:

>..........

> 

> After some more testing, I found I was mistaken about the loop being in 

> Reportlab graphics, instead it occurred later in a call to renderPM.  I 

> have a solution that seems to resolve the problem, but I still don't 

> fully understand the relationship of the filename case.

> 

> The problem seems to have been a race condition, and was set up by a web 

> page having two links to different PNG graph images that are created 

> upon demand.  The same Webware WebKit servlet is used to produce the PNG 

> graphs based upon the incoming CGI data. Per my googling, renderPM is 

> not thread-safe.  The solution was to put a lock around the call to 

> renderPM.drawToFile:

> 

> def makePng(drawing):

>     '''Convert a drawing to a PNG image and return it.'''

>     makePngLock.acquire()

>     sf = StringIO.StringIO('')

>     renderPM.drawToFile(drawing, sf,'PNG')

>     png = sf.getvalue()

>     makePngLock.release()

>     return png

> 

> Prior to putting in the lock I never saw the problem when using fonts 

> with filenames that had matched case, but had consistent failures when 

> using fonts with case mis-matched filenames.  Is it possible that the 

> mis-matched case in the font filenames is causing a reload of the font 

> that is not performed when the case matches?  That would be a plausible 

> explanation for the consistency for the success-failure related to fonts 

> used -- the first incoming request is slowed by I/O so the second 

> request always catches up and causes the threading problem.

> 

.......

Unfortunately no effort has yet been made to ensure that reportlab is thread 
safe. A particular problem is the font cache in pdfbase.pdfmetrics; 
unfortunately for historical reasons _renderPM.c has another cache related to 
the pfb files for T1 fonts (ttf fonts use the data from pdfmetrics).

I suspect if we tried to rewrite renderPM then freetype would be used throughout 
and probably the pfb data would be hacked onto the pdfmetrics font data in some 
way. Probably a two level cache would need to be used ie one level for all the 
actual data and another level to represent the view that a thread has of that 
data. I'm glad you were able to fix your problem by this means as I suspect I 
would be floundering in deep waters for any kind of short term fix.
-- 
Robin Becker