Sorry it took so long ... had to wait for renders. Removing the socket plug-in
from the build has fixed the errors.
Is there anything else you'd like me to test or information you'd like me to
provide regarding versions of
dependent libraries, etc?
As usual, thanks for replying so quickly.
-s
________________________________
From: Larry Gritz <[email protected]>
To: Stephen Parker <[email protected]>
Cc: OpenImageIO developers <[email protected]>
Sent: Friday, June 8, 2012 1:41 PM
Subject: Re: [Oiio-dev] epoll: too many files open ??
What I'm worried about is that it's trying every plugin on your file, and thus
coincidentally doing a lot of open() calls with the socket plugin even though
it's not needed, and maybe the socket plugin is leaking something inadvertently.
I'd also be curious if it's a problem for you in the master branch. We
recently overhauled the algorithm for plugin selection (being more careful
about trying the right plugin first, the one implied by the file extension, and
only as a last resort going through the whole list of plugins), and I don't
think that was backported to 1.0 since nobody had specifically complained about
it.
-- lg
On Jun 8, 2012, at 12:13 PM, Stephen Parker wrote:
This is in 1.0.4. I was actually in the process of removing the socket plug-in
when I wrote the list.
I'll follow-up shortly. We just discovered it this morning when looking
through some logs.
>
>
>
>________________________________
> From: Larry Gritz <[email protected]>
>To: Stephen Parker <[email protected]>; OpenImageIO developers
><[email protected]>
>Sent: Friday, June 8, 2012 11:55 AM
>Subject: Re: [Oiio-dev] epoll: too many files open ??
>
>
>Which branch?
>
>
>Just out of curiosity, what if you alter the src/CMakeLists.txt and
>src/libOpenImageIO/CMakeLists.txt to remove the references to socket.imageio,
>does that make the problem go away?
>
>
>
>
>
>
>On Jun 8, 2012, at 11:52 AM, Stephen Parker wrote:
>
>Hey,
>>
>>
>>A year or so ago we had some issues with file handles not being closed which
>>Larry promptly addressed and we haven't seen the problem again until
>>recently. This time however, the error message is a bit different - involving
>>epoll. From what I've gathered the only place this would be called is through
>>boost.asio and only as it pertains to iv and sockets. I haven't really dug
>>into it too far, but wanted to hit the list and see if anyone could offer up
>>a guess as to why we'd see this type of error when using the texture cache.
>>We're catching this exception inside a very thin wrapper around openimageio
>>at render time. This can be difficult to troubleshoot unless you've got
>>several thousand unique textures at your disposal (which is the case for us).
>>I'll continue to investigate but just thought I'd ask for an educated guess
>>first. I've set the maxfiles for the texture cache to half of what our ulimit
>>is - but the problem persists. I'm using boost 1.43, btw.
>>
>>
>>I'm not expecting a solution with what little information I've provided, but
>>I'll follow-up with more info and see if it warrants a bug report.
>>
>>
>>
>>-steve_______________________________________________
>>Oiio-dev mailing list
>>[email protected]
>>http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>
>
>--
>Larry Gritz
>[email protected]
>
>
>
>
>
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
