Date: Mon, 22 Nov 2004 01:28:39 -0500 From: Joe Marcus Clarke <marcus@marcuscom.com> To: Daniel Eischen <deischen@freebsd.org> Cc: freebsd-threads@freebsd.org Subject: Re: Question about our default pthread stack size Message-ID: <1101104919.95599.4.camel@gyros> In-Reply-To: <Pine.GSO.4.43.0411220058300.29589-100000@sea.ntplx.net> References: <Pine.GSO.4.43.0411220058300.29589-100000@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-r771LLZlfWLy4bhx52aU Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2004-11-22 at 01:15 -0500, Daniel Eischen wrote: > On Mon, 22 Nov 2004, Alexander Nedotsukov wrote: >=20 > > 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 her= e > > 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 32bi= t > > case :-) >=20 > 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. >=20 > 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 >=20 --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-r771LLZlfWLy4bhx52aU Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBoYcXb2iPiv4Uz4cRAh+EAJwKUFkPnKxoogX1GT5jTDUQqUW5bACfSNj1 WIMPoc3I++J6Qlq44xgj2iA= =fvhD -----END PGP SIGNATURE----- --=-r771LLZlfWLy4bhx52aU--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1101104919.95599.4.camel>