Date: Mon, 14 Feb 2005 14:56:06 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: Scott Long <scottl@freebsd.org> Cc: Joe Marcus Clarke <marcus@marcuscom.com> Subject: Re: cvs commit: src/lib/libpthread/thread thr_attr_init.cthr_init.c thr_private.h thr_stack.c Message-ID: <Pine.GSO.4.43.0502141445040.22143-100000@sea.ntplx.net> In-Reply-To: <4210D7B7.9090901@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 14 Feb 2005, Scott Long wrote: > Daniel Eischen wrote: > > >>* Joe Marcus Clarke <marcus@marcuscom.com> [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. <in-the-past> 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. </in-the-past> <now-in-libpthread> We have a larger default stacksize for the main thread, so this should solve any related problems that ports had. </now-in-libpthread> -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0502141445040.22143-100000>