From owner-cvs-src@FreeBSD.ORG Mon Feb 14 23:18:05 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 0F4EE16A4CE; Mon, 14 Feb 2005 23:18:05 +0000 (GMT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC7F643D1F; Mon, 14 Feb 2005 23:18:04 +0000 (GMT) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id D146E5C97C; Mon, 14 Feb 2005 15:18:04 -0800 (PST) Date: Tue, 15 Feb 2005 00:18:04 +0100 From: Maxime Henrion To: John-Mark Gurney Message-ID: <20050214231804.GD61763@elvis.mu.org> References: <421104E5.6040705@marcuscom.com> <20050214224901.GC61763@elvis.mu.org> <20050214231259.GH40468@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050214231259.GH40468@funkthat.com> User-Agent: Mutt/1.4.2.1i cc: src-committers@FreeBSD.org cc: cvs-src@FreeBSD.org cc: Alfred Perlstein cc: Scott Long cc: cvs-all@FreeBSD.org cc: Daniel Eischen cc: Joe Marcus Clarke Subject: Re: cvs commit: src/lib/libpthread/thread thr_attr_init.c thr_init.c thr_private.h thr_stack.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list 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 23:18:05 -0000 John-Mark Gurney wrote: > Maxime Henrion wrote this message on Mon, Feb 14, 2005 at 23:49 +0100: > > I entirely understand this and when I asked you why you weren't using > > pthread_attr_setstacksize() it was out of curiosity. Anyways, I'm > > surprised there's still an argument about this. __FreeBSD_version bumps > > are cheap, and if it can help reduce the maintainance burden of a port, > > I'm all for it. > > My point behind not doing a version bump is that if there is knowledge > that the program needs a large/small stack, then it should ALWAYS request > the stack size so that it is truely portable to all platforms.. instead > of trying to berate OS xyz into increasing their default stack size... > or end up breaking because this program tried to create 5000 threads, but > failed because each stack took up 1MB and required 5GB of ram on a 32bit > system.... I entirely agree with you but we can't blame this on the ports maintainers. If they want to go ahead, patch Gstreamer so that it requests reasonably sized stacks, and send the patch back to the vendors, that's great, but it seems that at least in the case of Gstreamer, it's hard to do due to how the application is designed. So we can't just refuse to bump __FreeBSD_version because Gstreamer has problems, especially considering how cheap a __FreeBSD_version bump is. > If the patch is applicable before the default change, then it is applicable > after, and if the patch is applicable after the default change, it was > applicable before... I also agree here. :-) Cheers, Maxime