[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Openexr-devel] OpenEXR from shared libs.

From: Jim Hourihan
Subject: Re: [Openexr-devel] OpenEXR from shared libs.
Date: Mon, 5 Mar 2007 14:41:42 -0800

On Mar 5, 2007, at 11:55 AM, Florian Kainz wrote:

The IlmImf library should set the stack size only for threads it
creates; it should not interfere with the stack size for application
threads.  (Is it even possible for a thread to change its own stack

The base pthreads API only allows it before creating the thread. I know you can overcome this limitation, but you have to move the stack to do it and this would invalidate cached pointers (and requires evil longjmp hackery as well). I think RT threads was implemented via multiple stacks in a single process using this technique. But it seems like overkill for EXR.

This brings up a disadvantage of changing the stack size: a thread
in a multithreaded application may use the small default stack size
and then call the IlmImf library in single-threaded mode (with the
number of threads set to 0).  In this case the AutoArrays will end
up on the application thread's small stack and cause a segfault.

I'm currently doing this (a separate reader thread is calling the library). However, I didn't find it unreasonable to be responsible for bumping the stack size up by a factor of four on my calling thread (on OS X) just to make sure. Anybody that's using pthreads (or mach threads) hopefully understands these issues.

Maybe it is better to use the heap-based AutoArray on systems where
threads have a small default stack size.

It seems like a configure option might be useful for the behavior of AutoArray. I'd like top performance and I'm willing to jump through some hoops to get it. Besides even on big-stack-size machines this problem still exists for some degenerate application code.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]