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
darby johnston <[EMAIL PROTECTED]> writes:
> How about a configure flag then?
>
> --enable-large-stack
> --disable-large-stack (default?)
That's a good idea. If the builder is sure that his platform supports
a "large stack," he can enable the feature for better performance.
d
pgp4KUGnHoWG
--- Drew Hess <[EMAIL PROTECTED]> wrote:
> Replacing the batch of platform check #ifdef's with
> a HAVE_LARGE_STACK
> symbol or something is a good idea; but
> auto-detecting the stack size
> by executing a program, if it's possible to do that
> reliably and
> portably, won't work for cross-compil
--- Paul Schneider <[EMAIL PROTECTED]> wrote:
> 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 Auto
Paul Schneider <[EMAIL PROTECTED]> writes:
> 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
--- Florian Kainz <[EMAIL PROTECTED]> 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
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 s
I wonder if other stack size issues exist?? When I do these two lines, I
get a crash:
Header head;
head.insert("comments", StringAttribute("Crash"));
I haven't investigated this, but it seg-fault's just like with the
AutoArray issue.
br - N :o)
Florian Kainz wrote:
I think Paul is right
Florian Kainz <[EMAIL PROTECTED]> writes:
> 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.
That is correct.
d
pgpasIWK4o2s1.pgp
Description: PG
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 sho
--- Paul Schneider <[EMAIL PROTECTED]> 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 8
I think this is a good solution for threads spawned by the library.
But don't we want to keep the AutoArray around for single-threaded
code, so that the EXR library doesn't change the stack size of the
thread that calls it? Or is there no such thing anymore? For some
reason I thought t
darby johnston wrote:
--- Florian Kainz <[EMAIL PROTECTED]> wrote:
Setting the stack size for the threads created by
the
IlmImf library seems to be the most satisfying
approach.
No additional preprocessor or configure script magic
is necessary, and BSD gets better performance by
allocating Au
--- Florian Kainz <[EMAIL PROTECTED]> wrote:
> Setting the stack size for the threads created by
> the
> IlmImf library seems to be the most satisfying
> approach.
> No additional preprocessor or configure script magic
> is necessary, and BSD gets better performance by
> allocating AutoArrays on t
14 matches
Mail list logo
