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

[Maxime Henrion]

John-Mark Gurney wrote:
> Maxime Henrion wrote this message on Mon, Feb 14, 2005 at 23:49 +0100:
> > 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.
> 
> My point behind not doing a version bump is that if there is knowledge
> that the program needs a large/small stack, then it should ALWAYS request
> the stack size so that it is truely portable to all platforms.. instead
> of trying to berate OS xyz into increasing their default stack size...
> or end up breaking because this program tried to create 5000 threads, but
> failed because each stack took up 1MB and required 5GB of ram on a 32bit
> system....

I entirely agree with you but we can't blame this on the ports
maintainers.  If they want to go ahead, patch Gstreamer so that it
requests reasonably sized stacks, and send the patch back to the
vendors, that's great, but it seems that at least in the case of
Gstreamer, it's hard to do due to how the application is designed.  So
we can't just refuse to bump __FreeBSD_version because Gstreamer has
problems, especially considering how cheap a __FreeBSD_version bump is.

> If the patch is applicable before the default change, then it is applicable
> after, and if the patch is applicable after the default change, it was
> applicable before...

I also agree here. :-)

Cheers,
Maxime