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 23:08 -0700, Scott Long wrote:
> 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.

Ah, okay, I misunderstood.  We've basically taken the static approach to
working around the problem with gstreamer.  We know we have (had) a 1 MB
limit, and thus we just replace the hardcoded 2 MB definition in
gstreamer with 1 MB.  The result is that most media operations do work,
but we still see some crashes with more complex formats.

As for "bending with it," that's the approach I'm forced to take many
times when porting Linux apps to FreeBSD.  We argued with the gstreamer
guys about doing things differently to accommodate a 1 MB stack, but
they just said it was too hard.

Joe

-- 
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-src/attachments/20050214/c9446106/attachment.bin