[reportlab-users] thread safe ?
Aaron Watters
reportlab-users@reportlab.com
Mon, 29 Jul 2002 09:39:50 -0400
--------------030102060708040106090309
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
There is also a number of *mutable* globals in platypus and maybe elsewhere
including the sequence thingy and I think the paragraph parser,
which dynamically change shared state. We'd need a general code
review to guarantee thread safety. I agree that these problems should
eventually
be eliminated regardless.
Personally, I really don't see any problem with launching subprocesses,
since there is no reason to use threads *inside* reportlab itself. The
only reason I can think of is that code that ReportLab is integrated
with is not flexible enough to allow subprocesses, which is not a
good reason in my book (unless we're paid, in which case the customer
is always right! :) ).
-- Aaron Watters
Andy Robinson wrote:
>>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
>_______________________________________________
>reportlab-users mailing list
>reportlab-users@reportlab.com
>http://two.pairlist.net/mailman/listinfo/reportlab-users
>
>
--------------030102060708040106090309
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<html>
<head>
</head>
<body>
There is also a number of *mutable* globals in platypus and maybe elsewhere<br>
including the sequence thingy and I think the paragraph parser,<br>
which dynamically change shared state. We'd need a general code<br>
review to guarantee thread safety. I agree that these problems should eventually<br>
be eliminated regardless.<br>
<br>
Personally, I really don't see any problem with launching subprocesses,<br>
since there is no reason to use threads *inside* reportlab itself. The<br>
only reason I can think of is that code that ReportLab is integrated<br>
with is not flexible enough to allow subprocesses, which is not a <br>
good reason in my book (unless we're paid, in which case the customer<br>
is always right! :) ).<br>
<br>
-- Aaron Watters<br>
<br>
Andy Robinson wrote:<br>
<blockquote type="cite" cite="mid:PGECLPOBGNBNKHNAGIJHIEJDDKAA.andy@reportlab.com">
<blockquote type="cite">
<pre wrap="">Dirk, the problem is that reportlab has global resources <br>which people<br>might want to change. For example a European might want to set the<br>default page size to A4 and before his code actuall uses it <br>an American<br>sets it back to letter.<br></pre>
</blockquote>
<pre wrap=""><!----><br>The real issues is that our own production apps at customer<br>sites are CGI based, so we just don't know. My feeling<br>is that we should publish a lost of "well known globals"<br>and how to use them; that this will probably work fine;<br>and if someone works within these guidelines and still<br>finds a bug, we treat it as a bug and fix it.<br><br>So, <br><br>Really dumb things to do with ReportLab in a multithreaded<br>environment:<br>(1) redefine constants like cm or inch in your app<br>(2) redefine standard color constants in reportlab/lib/colors<br>(3) redefine default page size (you can always set it<br>per document)<br>(4) have ambiguously named font encodings and subsets - e.g.<br>thread for a polish web user registers a corporate font with Central<br>European encoding and calls it 'FancyFont'; thread for English<br>web user resgiters one in WinAnsi and also calls it 'FancyFont'.<br>You'd be fine if you registered them with unique names l
ike<br>'FancyFont-WinAnsi'.<br><br>(5) two threads writing to the same PDF document - how<br>can you tell which order the pages will come out in ;-)<br>(6) two threads working on the same drawing.<br><br>Actually, (6) does make some sense; we initialize a <br>drawing, change some property and call draw many times.<br>Maybe we need to lock drawings when properties are being<br>changed and during draw. But since 90% of the work is<br>done in draw() and vey little in initialisation, making<br>one for each request probably would do fine for now.<br><br><br><br>Any more things we should warn of?<br><br>- Andy<br>_______________________________________________<br>reportlab-users mailing list<br><a class="moz-txt-link-abbreviated" href="mailto:reportlab-users@reportlab.com">reportlab-users@reportlab.com</a><br><a class="moz-txt-link-freetext" href="http://two.pairlist.net/mailman/listinfo/reportlab-users">http://two.pairlist.net/mailman/listinfo/reportlab-users</a><br><br><br></pre
>
</blockquote>
<br>
</body>
</html>
--------------030102060708040106090309--