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

[Joe Marcus Clarke]

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
> 
> 
> 
-- 
PGP Key : http://www.marcuscom.com/pgp.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/cvs-all/attachments/20050214/5a808669/attachment.bin