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
