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

[Jim Hourihan]

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
> size?)

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.

        -Jim