Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 19 Nov 2004 17:01:17 -0500
From:      Joe Marcus Clarke <marcus@FreeBSD.org>
To:        Daniel Eischen <deischen@FreeBSD.org>
Cc:        freebsd-threads@FreeBSD.org
Subject:   Re: Question about our default pthread stack size
Message-ID:  <419E6D2D.5040402@FreeBSD.org>
In-Reply-To: <Pine.GSO.4.43.0411191439340.17094-100000@sea.ntplx.net>
References:  <Pine.GSO.4.43.0411191439340.17094-100000@sea.ntplx.net>

next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel Eischen wrote:
| On Fri, 19 Nov 2004, Joe Marcus Clarke wrote:
|
|
|>Daniel Eischen wrote:
|>| The thing I worry about is these piggy applications being the
|>| driving force behind our stack size.  If they really are designed
|>| to need a huge stack size, they should be the ones that change
|>| to support it, not the other way around.  Do they know their own
|>| stack space requirements or do they just ignore it because it
|>| isn't a problem so far (on Linux)?
|>
|>The bottom line is that they don't know their stack requirements, but
|>the OS is accommodating, so they never have to really find out until we
|>submit a bug to them.  However, some applications (e.g. gstreamer,
|>libgnomecups, etc.) cannot be fixed without massive architectural
|>changes.  Just to be clear, these applications _are_ overrunning the
|>default stack.
|
|
| FYI, I don't suggest they change their stack usage, just that
| they create threads with thread attributes specifying a larger
| stack size.  If they recognize they have large stack space
| requirements, it should be easily solved without an architectural
| overhaul.

The problem is they don't realize they have such requirements until the
FreeBSD camp complains about weird crashes.

The architectural change to which I referred deals with GThreadPools.
There is no way to set a per-thread stack size with GThreadPools.
Therefore, I had to patch the source (glib20) such that all threads are
allocated with a default stack size of 1 MB unless a function is called
that explicitly sets a different size.

~  I assume your patches do exactly this; are the GNOME
| developers reluctant to incorporate your patches?

Yes.  I have brought these patches up to them, but they prefer not to
touch this code since FreeBSD seems to be the only platform affected.

|
| I'm not going to argue very strongly against changing the
| default stack size.  I just think the onus should be on
| the larger applications to recognize that they need larger
| stacks and to explicitly set it.  There may also be other
| applications that create a lot of threads which may need
| to lower the stack size if the default were changed.

That may be true, but I don't know of any such applications.  This is
something we can do in HEAD, and let it sit for a while to see if there
are any hidden problems.  If there are, we can always revert this
change.  However, I would imagine that those applications would have
already had problems on Solaris or Linux if that were the case.

Joe

|


- --
Joe Marcus Clarke
FreeBSD GNOME Team	::	gnome@FreeBSD.org
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBnm0sb2iPiv4Uz4cRAk3gAKCMFLftovlRk3f/f4XDdONlRJTg9QCglEGP
PhH7tz1ZPXT8rRKbOdgKC00=
=Inkz
-----END PGP SIGNATURE-----



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?419E6D2D.5040402>