[reportlab-users] Re: platypus.paragraph not thread safe (Robin Becker)

Andy Robinson andy at reportlab.com
Tue Jun 13 07:39:37 EDT 2006


> Thank you for the explanation. It works for me now with the changes I 
> sent. If it doesn't work in the long run I have to change the way I 
> create the pdf's.

Unfortunately just adding in your patch won't guarantee thread safety - 
there are a lot of places with module level variables.  The font cache 
is one of the main ones - it would be really easy to get into trouble 
about which fonts are preloaded and which are not, or with subsetting of 
TrueType fonts ending up with the wrong characters in the wrong 
document, or have documents behaving in an inconsistent manner.  These 
problems would be hell to reproduce and trace.  Also, we'd lose a lot of 
performance by introducing per-document font caches and by 
reinitialising parsers on each paragraph.

I would prefer just to tell everyone clearly that, at the moment, it's 
"thread-dangerous".   We MIGHT revisit this in ReportLab 3.0 (3000?) if 
we did a major pass through the code, but not soon.

We would suggest that anyone using our framework within Zope or another 
multithreaded environment wraps their entry-point for PDF-making in a 
synchronized block, so only one job is active at a time, or uses the 
Queue module in the standard library, or starts a separate process. 
I'll try to make sure this is documented more clearly in the user guide.

I realise this may sound like a strange attitude.  However many of the 
smartest and wisest programmers I have ever known have warned us away 
from threaded apps.  This includes Guido, Gordon McMillan, Mark Hammond, 
Greg Stein and many more.  Jeff Bauer said it beautifully:  "If you 
think you're smart enough to write multi-threaded code, you aren't!"

So, when we build PDF-making servers for clients, which is all the time, 
we start a separate process.  This guarantees reproducibility, lets you 
take full advantage of multiple CPUs, lets you monitor job memory use, 
lets you separate out the input data for each report, and many more 
things. It also ensures that any problems in user written code in the 
report scripts cannot impact the web server.

Best regards,


Andy Robinson



More information about the reportlab-users mailing list