Date: Mon, 14 Feb 2005 01:15:32 -0500 From: Joe Marcus Clarke <marcus@marcuscom.com> To: Scott Long <scottl@samsco.org> Cc: Sam Leffler <sam@errno.com> Subject: Re: cvs commit: src/lib/libpthread/thread thr_attr_init.c thr_init.c thr_private.h thr_stack.c Message-ID: <1108361732.93267.35.camel@shumai.marcuscom.com> In-Reply-To: <42104071.7020003@samsco.org> References: <200502131838.j1DIc6tZ020690@repoman.freebsd.org> <1108337583.93267.1.camel@shumai.marcuscom.com> <20050214020531.GD40468@funkthat.com> <1108352249.93267.20.camel@shumai.marcuscom.com> <20050214040349.GA61763@elvis.mu.org> <1108355421.93267.23.camel@shumai.marcuscom.com> <42102C54.4000408@errno.com> <1108360361.93267.26.camel@shumai.marcuscom.com> <42104071.7020003@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-QS3HYFSg3bG3Gyxp0EKB Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2005-02-13 at 23:08 -0700, Scott Long wrote: > Joe Marcus Clarke wrote: >=20 > > On Sun, 2005-02-13 at 20:43 -0800, Sam Leffler wrote: > >=20 > >>Joe Marcus Clarke wrote: > >> > >>>On Mon, 2005-02-14 at 05:03 +0100, Maxime Henrion wrote: > >>> > >>> > >>>>Joe Marcus Clarke wrote: > >>>> > >>>> > >>>>>On Sun, 2005-02-13 at 18:05 -0800, John-Mark Gurney wrote: > >>>>> > >>>>> > >>>>>>Joe Marcus Clarke wrote this message on Sun, Feb 13, 2005 at 18:33 = -0500: > >>>>>> > >>>>>> > >>>>>>>And there was much rejoicing! I would like to reiterate mezz's re= quest > >>>>>>>for a __FreeBSD_version bump once all the thread libraries are upd= ated. > >>>>>>>It would also be good to get this MFC'd before 5.4. Thanks again. > >>>>>> > >>>>>>If any application that cares/requires changes from the default, ei= ther > >>>>>>due to large number of threads (requiring small stack size), or lar= ge > >>>>>>stacks, should already be patched with their new defaults... So > >>>>>>requiring a modification based upon version before/after this chang= e > >>>>>>should be unnecessary... > >>>>> > >>>>>But knowing when this patch is implemented means we can _not_ patch > >>>>>certain applications. The best example of this is gstreamer. Gstre= amer > >>>>>is patched to lower its initial thread stack usage to 1 MB since tha= t > >>>>>was the previous limit. This severely limits gstreamer. With the > >>>>>larger initial thread stack size (something that is not changeable b= y > >>>>>individual applications), we no longer need to cripple gstreamer on > >>>>>-CURRENT. Therefore, I ask __FreeBSD_version to be bumped so I know > >>>>>when it's safe to let gstreamer take a full 2 MB of stack on the ini= tial > >>>>>thread. > >>>> > >>>>Is there anything wrong with pthread_attr_setstacksize()? Using this= to > >>>>patch the said applications would allow them to get an acceptably siz= ed > >>>>stack whether the host is running an old or a recent version of > >>>>libpthread. It would also make sense to then submit the patches to t= he > >>>>vendor so that it's not too much a burden to maintain. > >>> > >>> > >>>This works for all threads but the initial thread. Gstreamer uses thi= s > >>>thread for most of its operations. That stack size was set to be 1 MB > >>>when gstreamer really wanted 2. For all other thread problems, yes, I > >>>used pthread_attr_setstacksize() as the solution. > >> > >>Sounds like this should be a tunable in the kernel if you it's really=20 > >>needed early on. I'm not familiar with the thread support but glancing= =20 > >>at the diffs make it looks like the compile-time define was mostly=20 > >>eliminated so now it's just a question of finding a good place to get a= =20 > >>starting value. > >=20 > >=20 > > Looks like the compile-time options are still there, it's just now > > dependent on sizeof(void *). In any event, even if kernel tunables are > > added, we need some way of knowing when that is from a userland (i.e. > > ports) perspective, hence my request for a __FreeBSD_version bump when > > the stacksize transition is complete. > >=20 > > Joe > >=20 > >=20 > >> Sam > >> > >> > >> >=20 > I think what Sam is saying is that the program should query a sysctl to > find out the size of the primary stack, and then adjust its stack use > at runtime based on this. This definitely has advantages, but it would > definitely also add a whole lot of code that would be hard to push back > to the ports authors. I'll say that some of the stack abuse that I've > seen in threaded programs is pretty dumb, but at the end of the day it > winds up being a lot easier to just bend with it than to try to convince > the authors of the better way or to maintain complex patches in the > ports tree. Ah, okay, I misunderstood. We've basically taken the static approach to working around the problem with gstreamer. We know we have (had) a 1 MB limit, and thus we just replace the hardcoded 2 MB definition in gstreamer with 1 MB. The result is that most media operations do work, but we still see some crashes with more complex formats. As for "bending with it," that's the approach I'm forced to take many times when porting Linux apps to FreeBSD. We argued with the gstreamer guys about doing things differently to accommodate a 1 MB stack, but they just said it was too hard. Joe --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-QS3HYFSg3bG3Gyxp0EKB Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCEEIEb2iPiv4Uz4cRAje1AKCkdBOUlFLPp65KaApEwTruRJ5QZgCgiw4y tsN+oSA3vJUyy+7J90udfJc= =Kom5 -----END PGP SIGNATURE----- --=-QS3HYFSg3bG3Gyxp0EKB--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1108361732.93267.35.camel>