[reportlab-users] Intermittent failure to find font, followed by IOError
carl at personnelware.com
Wed Nov 4 14:48:00 EST 2009
Anytime someone gets close to this subject I point them to:
"David Beazley: mind-blowing presentation about how the Python GIL
actually works and why it's even worse than most people even imagine."
On Wed, Nov 4, 2009 at 1:10 PM, Stevens, Ian <IStevens at globeandmail.com> wrote:
> Thanks Robin. This link may shed some light:
> "Note that if any third party module is being used which has a C code component that uses the simplified API for access to the Global Interpreter Lock (GIL) for Python extension modules, then the interpreter name must be forcibly set to be 'main_interpreter'. This is necessary as such a module will only work correctly if run within the context of the first Python interpreter created by the process. If not forced to run under the 'main_interpreter', a range of Python errors can arise, each typically referring to code being run in restricted mode."
> "Default behaviour is to name interpreters using the Apache virtual server name (ServerName directive). This means that all scripts in the same virtual server execute in the same subinterpreter, but scripts in different virtual servers execute in different subinterpreters with completely separate namespaces."
> We are using the same codebase for several different domain names. I suppose it is possible that some objects are being shared across domains, and subsequently over interpreters as well. It might be a coincidence, but over 95% of the URLs which generate these errors are on the same subdomain even though they account for nowhere near 95% of the traffic.
>> -----Original Message-----
>> From: reportlab-users-bounces at lists2.reportlab.com
>> [mailto:reportlab-users-bounces at lists2.reportlab.com] On
>> Behalf Of Robin Becker
>> Sent: November 4, 2009 5:37 AM
>> To: For users of Reportlab open source software
>> Subject: Re: [reportlab-users] Intermittent failure to find
>> font, followed by IOError
>> Stevens, Ian wrote:
>> > Hi Robin. Thanks for the patch. It's been applied, and now
>> we get the following:
>> > File
>> .py", line 79, in parseAFMFile
>> > lines = open_and_readlines(afmFileName, 'r')
>> > File
>> line 462, in open_and_readlines
>> > return open_and_read(name,mode).split('\n')
>> > File
>> line 459, in open_and_read
>> > return open_for_read(name,mode).read()
>> > File
>> line 454, in open_for_read
>> > dbg.dump()
>> > File
>> line 810, in dump
>> > f = open(self.fn,'wb')
>> > IOError: file() constructor not accessible in
>> restricted mode, while looking for faceName='AGFScalaSansBold'
>> > The faceName matches one which is registered before any
>> other PDF work is done. The IOError is the DebugMemo.dump()
>> failing. I've never seen that error before. Could it be
>> another symptom of the same issue? The original open() for
>> the font could be raising this error. Could it be a
>> side-effect of a mod_python configuration?
>> I think you're right; if open (ie alias of file) is not
>> availble in the dump then it might well be the problem in the
>> original open.
>> Googling for the error message "IOError: file() constructor
>> not accessible in restricted mode" seems to indicate that it
>> might be related to rexec/mod_python.
>> This link seems to bear out my opinion that Python restricted
>> mode ought to be considered useless
>> this email
>> seems to imply this has been seen in mod_python land before.
>> I think the implication of the latter is that code is being
>> executed in the wrong thread. I will try asking about this on clp.
>> > FYI, we're running Python 2.5.2 and mod_python 3.3.1.
>> > Thanks,
>> > Ian.
>> Robin Becker
>> reportlab-users mailing list
>> reportlab-users at lists2.reportlab.com
> reportlab-users mailing list
> reportlab-users at lists2.reportlab.com
More information about the reportlab-users