[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Openexr-devel] Thread safety
From: |
Larry Gritz |
Subject: |
Re: [Openexr-devel] Thread safety |
Date: |
Tue, 2 Apr 2013 16:25:27 -0700 |
Ah, I see, thanks for the explanation, Peter.
> (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?
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 (which, duh, of course I should have spotted as the kind of
non-atomicity that would be the fatal flaw). I may be able to finagle a way to
make a lock just around the setFramebuffer/readTiles pair.
> 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.
--
Larry Gritz
address@hidden
- [Openexr-devel] Thread safety, Larry Gritz, 2013/04/02
- Re: [Openexr-devel] Thread safety, Peter Hillman, 2013/04/02
- Re: [Openexr-devel] Thread safety,
Larry Gritz <=
- Re: [Openexr-devel] Thread safety, Peter Hillman, 2013/04/02
- Re: [Openexr-devel] Thread safety, Christopher Horvath, 2013/04/03
- Re: [Openexr-devel] Thread safety, Piotr Stanczyk, 2013/04/03
- Re: [Openexr-devel] Thread safety, Christopher Horvath, 2013/04/03
- Re: [Openexr-devel] Thread safety, Piotr Stanczyk, 2013/04/03
- Re: [Openexr-devel] Thread safety, Bob Friesenhahn, 2013/04/03
- Re: [Openexr-devel] Thread safety, Brendan Bolles, 2013/04/03
- Re: [Openexr-devel] Thread safety, Paul Miller, 2013/04/04
Re: [Openexr-devel] Thread safety, jcupitt, 2013/04/03