I was just having the same conversation yesterday... I think I would like to see an abstraction where you can sub in your own implementation with a fallback to the current one.
Anyone have strong thoughts / opinions on this? Is this something that people would like to be able to configure at build time or runrtime? ________________________________ From: openexr-devel-bounces+pstanczyk=ilm....@nongnu.org [openexr-devel-bounces+pstanczyk=ilm....@nongnu.org] on behalf of Christopher Horvath [blackenc...@gmail.com] Sent: 03 April 2013 08:44 To: Peter Hillman Cc: openexr-devel@nongnu.org Subject: Re: [Openexr-devel] Thread safety Is there any hope for IlmThread being retired in favor of OpenMP, TBB, or the C++ 11 std threads library? On Tue, Apr 2, 2013 at 6:23 PM, Peter Hillman <pet...@wetafx.co.nz<mailto:pet...@wetafx.co.nz>> wrote: On 04/03/2013 12:25 PM, Larry Gritz wrote: (This does assume that IlmThread's Lock mechanism is compatible with the way your threads are created). I'm not sure I followed that statement. Huh? I'd understood that there are some high performance threading libraries which aren't pthread compatible. On Posix systems, for example, IlmThread::Mutex::lock() calls pthread_mutex_lock(). This might not actually lock the thread if it is some exotic thread implementation unrelated to pthread. If you are using pthread, windows threads, or better still the IlmThread library, all will be well. My threads do each set up separate frame buffers. It's too bad the framebuffer isn't an argument to readPixels/readTiles rather than set by a separate call to setFrameBuffer There'd be little point in passing a framebuffer to readpixels unless the file read is separated from decoding the pixel data, in the same way that the rawpixel approach does in deepscanlines. Under the hood, it might as well just do a lock, setframebuffer, readpixels, unlock. It might be worth extending the deepscanline rawpixel approach to regular images As always, the fastest way to read EXRs is to read as much of the file as possible in a single call, and let the EXR library manage its own threads. Ha ha, yeah, until you have 2 TB of image files you're accessing incoherently. Oh dear. Perhaps it might be worth the effort of implementing some super system with a single thread that handles calls to readPixels/readTiles, with other threads post requests to that and wait for the reply. That thread can reorder the requests to reduce the amount of file seeking that takes place. I'm guessing that file seeks are far more expensive than decoding pixels. Rather you than me :-) Peter _______________________________________________ Openexr-devel mailing list Openexr-devel@nongnu.org<mailto:Openexr-devel@nongnu.org> https://lists.nongnu.org/mailman/listinfo/openexr-devel -- I think this situation absolutely requires that a really futile and stupid gesture be done on somebody's part. And we're just the guys to do it.
_______________________________________________ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel
