cvs commit: src/lib/libpthread/thread thr_attr_init.c thr_init.c thr_private.h thr_stack.c

[Maxime Henrion]

Joe Marcus Clarke wrote:
> Daniel Eischen wrote:
> | On Mon, 14 Feb 2005, Scott Long wrote:
> |
> |
> |>Daniel Eischen wrote:
> |>
> |>
> |>>>* Joe Marcus Clarke <marcus at 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>
> 
> I couldn't find an easy way to do that with cothreads in gstreamer.
> However, this is exactly what I did with other ports.
> 
> |
> | <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>
> 
> Yep, and I'm happy to have it (don't get me wrong).  However, I was
> hoping to have a way to know when it was safe to remove at least the
> gstreamer hack, and that's why I asked for the __FreeBSD_version bump.

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.

Cheers,
Maxime