[reportlab-users] file handle limits :(

Robin Becker reportlab-users@reportlab.com
Thu, 11 Sep 2003 14:22:22 +0100


In article <bjnc2k$2p1bh$1@hades.rz.uni-saarland.de>, Michael Schmitt
<nomail@nomail.com> writes
>Hello.
>
>I am trying to build a pdf document using:
>---
>from reportlab.platypus.flowables import Image
>lst = []
>for filename in imageFiles:
>    I= Image(filename, width= 300, height= 300)
>    lst.append(I)
>---
>Creating an Image object seems to open a filehandle, so if the size of 
>imageFiles increases, I get "IOError: [Errno 24] Too many open files" on a 
>Solaris machine, where the number of simultaneously opened filehandles 
>seems to be limited to roughly 255.
>
>Is there a way to produce a pdf document with a large number of images 
>without running into the problem of too many open filehandles?
>
>Thanks for any hints.
>Michael
>

We've recently begun changing the code for images to assist in a port to
jython. I believe the problem still exists.

in the ImageReader __init__ we have code like

                #detect which library we are using and open the image
                if sys.platform[0:4] == 'java':
                        from javax.imageio import ImageIO
                        from java.io import File
                        self._image = ImageIO.read(File(fileName))
                else:
                        import PIL.Image
                        self._image = PIL.Image.open(fileName)

I guess the problem here is that we don't open or close the file
explicitly in our code. I think that we could delay opening the image
until it's actually needed. PIL's open doesn't seem to explicitly close
its files.

If a document had 300 images we'd currently have all those file pointers
open before rendering started and the Image object could be thrown away.

Unfortunately the reportlab.platypus.Image flowable class want's to open
the image in it's init so there wouldn't be much delay unless we push
the laziness in there as well.

I will copy this into the reportlab-users list for others to comment on.

>

-- 
Robin Becker