[reportlab-users] thread safe ?

[Andy Robinson]

> Dirk, the problem is that reportlab has  global resources 
> which people
> might want to change. For example a European might want to set the
> default page size to A4 and before his code actuall uses it 
> an American
> sets it back to letter.

The real issues is that our own production apps at customer
sites are CGI based, so we just don't know.  My feeling
is that we should publish a lost of "well known globals"
and how to use them; that this will probably work fine;
and if someone works within these guidelines and still
finds a bug, we treat it as a bug and fix it.

So, 

Really dumb things to do with ReportLab in a multithreaded
environment:
(1) redefine constants like cm or inch in your app
(2) redefine standard color constants in reportlab/lib/colors
(3) redefine default page size (you can always set it
per document)
(4) have ambiguously named font encodings and subsets - e.g.
thread for a polish web user registers a corporate font with Central
European encoding and calls it 'FancyFont'; thread for English
web user resgiters one in WinAnsi and also calls it 'FancyFont'.
You'd be fine if you registered them with unique names like
'FancyFont-WinAnsi'.

(5) two threads writing to the same PDF document - how
can you tell which order the pages will come out in ;-)
(6) two threads working on the same drawing.

Actually, (6) does make some sense; we initialize a 
drawing, change some property and call draw many times.
Maybe we need to lock drawings when properties are being
changed and during draw.  But since 90% of the work is
done in draw() and vey little in initialisation, making
one for each request probably would do fine for now.



Any more things we should warn of?

- Andy