From owner-cvs-src@FreeBSD.ORG Mon Feb 14 19:56:08 2005 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4378116A4DB; Mon, 14 Feb 2005 19:56:08 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9FAF43D4C; Mon, 14 Feb 2005 19:56:07 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) j1EJu69O003705; Mon, 14 Feb 2005 14:56:06 -0500 (EST) Date: Mon, 14 Feb 2005 14:56:06 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Scott Long In-Reply-To: <4210D7B7.9090901@freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: John-Mark Gurney cc: src-committers@freebsd.org cc: Maxime Henrion cc: cvs-src@freebsd.org cc: Alfred Perlstein cc: cvs-all@freebsd.org cc: Joe Marcus Clarke Subject: Re: cvs commit: src/lib/libpthread/thread thr_attr_init.cthr_init.c thr_private.h thr_stack.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2005 19:56:08 -0000 On Mon, 14 Feb 2005, Scott Long wrote: > Daniel Eischen wrote: > > >>* Joe Marcus Clarke [050213 20:30] wrote: > >> > >>>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. > >> > >>Can't you wrap main and bounce into it with a thread that has been > >>created using pthread_attr_setstacksize()? > > > > > > Exactly! > > > > Again, I think that you have to look at the problem of supporting apps > that are written in a linux-centric way by authors who aren't interested > in merging back changes that complicate the code. I (think) we're talking about existing patches to ports. The simple way get a bigger main thread stack is to create another thread with larger stack to run whatever main runs. There wasn't a need to have ports with reduced functionality just because the main thread's stack wasn't large enough. We have a larger default stacksize for the main thread, so this should solve any related problems that ports had. -- DE