Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 10 Feb 2004 20:13:01 -0500 (EST)
From:      Daniel Eischen <eischen@vigrid.com>
To:        Julian Elischer <julian@elischer.org>
Cc:        freebsd-threads@freebsd.org
Subject:   Re: Question about threads [beaver challenge]
Message-ID:  <Pine.GSO.4.10.10402102008580.4671-100000@pcnet5.pcnet.com>
In-Reply-To: <Pine.BSF.4.21.0402101705210.82714-100000@InterJet.elischer.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 10 Feb 2004, Julian Elischer wrote:

> 
> 
> On Tue, 10 Feb 2004, Craig Rodrigues wrote:
> 
> > On Tue, Feb 10, 2004 at 06:22:28PM -0500, Daniel Eischen wrote:
> > > That's why I wanted to know what top -H showed.  We saw the
> > > same problem with python -- it was using system scope threads
> > > by default.  The port has since been changed to use process
> > > scope threads.
> > 
> > Is this a Linux-ism that we will need to be aware of
> > for other ports that use pthreads?

Probably, yes.

> 
> process scope threads a re perfectly reasonable.. they however
> use more resources and are more heavily limitted.
> 
> 
> On the other hand process scope threads can lead to nasty surprises with
> the limits as they can "suddenly" hit th ekernel limit after running
> usccessfully for a time when they all (by some fluke) all decide to
> enter the kernel at the same time.

Well, since the kernel limit for scope system threads is much smaller
than that for "threads blocked in kernel", you'd hit the limit much
sooner if the port/application used scope system threads instead
of scope process threads.

> We probably should increase the  limits from 150 and 50 to 
> 600 and 300 or something.

That's fine by me.  It's all a guessing game for me 'cause I
don't really know what you'd expect to see with some of these
applications.

-- 
Dan Eischen



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10402102008580.4671-100000>