Date: Mon, 22 Nov 2004 01:15:08 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: Alexander Nedotsukov <bland@freebsd.org> Cc: freebsd-threads@freebsd.org Subject: Re: Question about our default pthread stack size Message-ID: <Pine.GSO.4.43.0411220058300.29589-100000@sea.ntplx.net> In-Reply-To: <41A17D9D.4050502@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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... -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0411220058300.29589-100000>