From owner-cvs-all@FreeBSD.ORG Mon Feb 14 04:42:26 2005 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 087A316A4CE; Mon, 14 Feb 2005 04:42:26 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9276443D31; Mon, 14 Feb 2005 04:42:25 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.89] ([66.127.85.89]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j1E4gOWi054742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Feb 2005 20:42:25 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <42102C54.4000408@errno.com> Date: Sun, 13 Feb 2005 20:43:00 -0800 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Marcus Clarke 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> In-Reply-To: <1108355421.93267.23.camel@shumai.marcuscom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: John-Mark Gurney cc: src-committers@FreeBSD.org cc: Maxime Henrion cc: cvs-src@FreeBSD.org cc: cvs-all@FreeBSD.org cc: Daniel Eischen Subject: Re: cvs commit: src/lib/libpthread/thread thr_attr_init.cthr_init.c thr_private.h thr_stack.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2005 04:42:26 -0000 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 request >>>>>for a __FreeBSD_version bump once all the thread libraries are updated. >>>>>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, either >>>>due to large number of threads (requiring small stack size), or large >>>>stacks, should already be patched with their new defaults... So >>>>requiring a modification based upon version before/after this change >>>>should be unnecessary... >>> >>>But knowing when this patch is implemented means we can _not_ patch >>>certain applications. The best example of this is gstreamer. Gstreamer >>>is patched to lower its initial thread stack usage to 1 MB since that >>>was the previous limit. This severely limits gstreamer. With the >>>larger initial thread stack size (something that is not changeable by >>>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 initial >>>thread. >> >>Is there anything wrong with pthread_attr_setstacksize()? Using this to >>patch the said applications would allow them to get an acceptably sized >>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 the >>vendor so that it's not too much a burden to maintain. > > > This works for all threads but the initial thread. Gstreamer uses this > 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 needed early on. I'm not familiar with the thread support but glancing at the diffs make it looks like the compile-time define was mostly eliminated so now it's just a question of finding a good place to get a starting value. Sam