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

[Paul Schneider]

> I think Paul is right; we added the AutoArray to IlmImf before
> we added threading.  If I remember correctly, the AutoArray was
> introduced specifically to address the small stack size on OS X.
> Maybe this has changed, and the AutoArray is no longer necessary
> on newer systems.

At one point last summer, I was experimenting with making a test  
program that would detect large stack support.  The idea was that the  
"configure" script could run this test program, and then define a  
HAVE_LARGE_STACK symbol that would replace the current OS-specific  
check.  I was surprised to find that on OS X 10.4, I was able to  
write a simple test program that pushed an array onto the stack that  
was the same size as those used by IlmImf.  But, the confidence tests  
still crashed if I disabled the AutoArray for OS X.

I didn't look into it more closely, but maybe the problem was that  
the IlmImf code was running on threads with much smaller stacks than  
my single-threaded test app.  I think that threaded IO had been added  
to OpenEXR when I tried this experiment.

And Florian's right, the AutoArray predates threading and was  
originally added to avoid problems with small fixed-size stacks on  
the Mac.  It came in handy when OpenEXR was ported to Windows, which  
also seems to have small fixed-size stacks.

- Paul


On Mar 5, 2007, at 2:55 PM, Florian Kainz wrote:

> I think Paul is right; we added the AutoArray to IlmImf before
> we added threading.  If I remember correctly, the AutoArray was
> introduced specifically to address the small stack size on OS X.
> Maybe this has changed, and the AutoArray is no longer necessary
> on newer systems.
>
> 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?)
>
> 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.
>
> Maybe it is better to use the heap-based AutoArray on systems where
> threads have a small default stack size.
>
> Florian
>
> darby johnston wrote:
> > --- Paul Schneider <address@hidden> wrote:
> >
> > > But don't we want to keep the AutoArray around for
> > > single-threaded code
> > I believe the default stack size for processes is much
> > larger than threads, so it shouldn't be an issue.
> > For instance, according to this the default stack size
> > in OSX is 8MB, but for pthreads is only 512KB:
> > http://developer.apple.com/qa/qa2005/qa1419.html
> > > so that the EXR library doesn't change the
> > > stack size of the  thread that calls it?
> > The change will be specific to the pthreads stuff, so
> > if you disable threading it won't affect anything. -- Florian  
> > Kainz <address@hidden> wrote:
> > > darby johnston wrote:
> > > > Also, could the ifdef for darwin in ImfAutoArray.h
> > > be
> > > > removed with this change?
> > > I don't know.  Have you tried it?
> > Unfortunately I don't have access to a mac, but the
> > above document seems to support it.
> > Darby
> > _______________________________________________
> > Openexr-devel mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/openexr-devel
>
>
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/openexr-devel