Question about our default pthread stack size

[Joe Marcus Clarke]

On Mon, 2004-11-22 at 01:15 -0500, Daniel Eischen wrote:
> On Mon, 22 Nov 2004, Alexander Nedotsukov wrote:
> 
> > Daniel Eischen wrote:
> >
> >     Heavy stack usage is not so evil like it may look like. That "pig"
> > will have to allocate big memory chunk anyway and the usual options here
> > are to grab phys memory page on the heap through the malloc() or do it
> > on the stack. In both of the cases this memory will not be immediately
> > allocated. But malloc() way will be slower and this is why multimedia
> > processing code may prefer on stack allocation. Another malloc/free()
> > disadvantage for C program is potential memory leakage. People may feel
> > safer when they don't have to check all return paths but get automatic
> > memory disposal.
> > One more thing about "Do they know their own stack space requirements".
> > No they don't. And the whole idea here I believe was to let them don't
> > care at all. I doubt very much if such research for something like
> > OpenOffice will worth the efforts. So it is more practical to follow
> > Bill's like "no one can beat xxx barrier". Where xxx is 1MB in our 32bit
> > case :-)
> 
> You're missing my point.  There is a perfectly good POSIX standard for
> setting thread stack size -- you don't even need to allocate it yourself.
> Using pthread_attr_setstacksize() is more portable than relying on
> the OS to guess at what an application's stack size requirements are.
> We may increase it to 1MB now, but what happens when that is not enough?
> And you _know_ one day, perhaps sooner than you realize, that it won't
> be enough.

Okay, but I still don't see the reason for not increasing the stack size
now to be more inline with Solaris and Linux.  We seem to be adopting
other Solaris-like threading attributes (based on some of your previous
emails), and this would help other popular software packages "just work"
on FreeBSD.

> 
> I've searched the GTK archives and can see that the stack size was
> removed from the thread pool api, but not from creating other threads.
> The reason for removing it seems silly, but such is life...

Right.  You can still create individual threads, and specify a
per-thread stack size.  However, this cannot be done with GThreadPools.

Joe

> 
-- 
PGP Key : http://www.marcuscom.com/pgp.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-threads/attachments/20041122/0f2c763b/attachment.bin