[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