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

[Scott Long]

Joe Marcus Clarke wrote:

> On Sun, 2005-02-13 at 20:43 -0800, Sam Leffler wrote:
> 
>>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.
> 
> 
> Looks like the compile-time options are still there, it's just now
> dependent on sizeof(void *).  In any event, even if kernel tunables are
> added, we need some way of knowing when that is from a userland (i.e.
> ports) perspective, hence my request for a __FreeBSD_version bump when
> the stacksize transition is complete.
> 
> Joe
> 
> 
>>	Sam
>>
>>
>>

I think what Sam is saying is that the program should query a sysctl to
find out the size of the primary stack, and then adjust its stack use
at runtime based on this.  This definitely has advantages, but it would
definitely also add a whole lot of code that would be hard to push back
to the ports authors.  I'll say that some of the stack abuse that I've
seen in threaded programs is pretty dumb, but at the end of the day it
winds up being a lot easier to just bend with it than to try to convince
the authors of the better way or to maintain complex patches in the
ports tree.

So for the record, I agree that __FreeBSD_version needs an update for
this change.

Scott