Date: Fri, 19 Nov 2004 13:17:04 -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: <419E38A0.2030308@marcuscom.com> In-Reply-To: <Pine.GSO.4.43.0411191256430.16359-100000@sea.ntplx.net> References: <Pine.GSO.4.43.0411191256430.16359-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: | | |>-----BEGIN PGP SIGNED MESSAGE----- |>Hash: SHA1 |> |>Daniel Eischen wrote: |>| On Fri, 19 Nov 2004, Alexander Nedotsukov wrote: |>| |>| |>|>Hey guys, |>|> |>|>After squashing yet another "too small thread stack size" bug in |>|>software developed on Linux. I decided to ask gurus for the comment. Why |>|>we still insist that 64K is good enough for 32bit archs? I do understand |>| |>| |>| I suggested we double the stack size for 64-bit archs (making it |>| 128K). I could see going to 256K for 32-bit and 512K for 64-bit. |> |>ia64 already uses a 256 KB default stack size. However, I argue that is |>is "too small." Linux has a much higher default (inline with the |>document bland referenced), and thus, most popular multithreaded |>applications are developed with that in mind. |> |>It has become some problematic for GNOME, for example, that I have |>hacked glib20 to allocate a default 1 MB stack on all architectures |>(this is, of course, configurable). | | | 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. ~ What if they need more than | 1MB in a few months (Bill Gates -- who's ever going to need | more than 64K ;-)? Are we going to change again? It was 640 K, but I get the point. Honestly, I think we _do_ have to change with the industry. We can't be the Bill Gates, and say a 64 K default stack size should be good enough. | | I can see raising the default stack size, but 1MB (32-bit) and | 2MB (64-bit) seem kinda large. Why? Remember, this is just a _default_. Developers that know their stack requirements can lower this down to 16 K (IIRC). However, the developers that are programming these pigs (popular pigs, mind you), will find that FreeBSD behaves just like Solaris and Linux. That might entice them to continue their efforts on FreeBSD. Speaking for myself, debugging stack overruns aren't the easiest thing, and I would imagine random crashes in one's application might discourage people from developing on FreeBSD. Joe | - -- PGP Key : http://www.marcuscom.com/pgp.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBnjigb2iPiv4Uz4cRAsubAKCX4vu3GGJoKOhV6gTn5yKDoruEQQCeJ2uG 6aMobmkKosPUg6O+vgrG8Ow= =mp6z -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?419E38A0.2030308>