|
From: | Christopher Horvath |
Subject: | Re: [Openexr-devel] Thread safety |
Date: | Wed, 3 Apr 2013 09:17:59 -0700 |
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=address@hidden [openexr-devel-bounces+pstanczyk=address@hidden] on behalf of Christopher Horvath [address@hidden]
Sent: 03 April 2013 08:44
To: Peter Hillman
Cc: address@hidden
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 <address@hidden> wrote:
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.
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?
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.
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
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 imagesOh 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.
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.
Rather you than me :-)
Peter
_______________________________________________
Openexr-devel mailing list
address@hidden
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.
[Prev in Thread] | Current Thread | [Next in Thread] |