Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU by po7.MIT.EDU (5.61/4.7) id AA03974; Fri, 12 Jan 96 19:54:30 EST
Received: from [206.112.192.127] by MIT.EDU with SMTP
	id AC24754; Fri, 12 Jan 96 19:54:31 EST
Received: (from listadm@localhost) by liquor.cabi.net (8.6.12/8.6.12) id TAA12382; Fri, 12 Jan 1996 19:54:47 -0500
Resent-Date: Fri, 12 Jan 1996 19:54:47 -0500
Date: Fri, 12 Jan 1996 16:53:16 -0800 (PST)
From: Michael Bayne <mbayne@qualcomm.com>
To: java-linux@java.blackdown.org
Subject: Re: Threads and time quantum
In-Reply-To: <Pine.SUN.3.91.960112233124.2004A-100000@despina>
Message-Id: <Pine.sol.3.91.960112164624.18285A-100000@ginkgo.qualcomm.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Resent-Message-Id: <"0uvgZ3.0.k03.vAmzm"@liquor>
Resent-From: java-linux@java.blackdown.org
X-Mailing-List: <java-linux@java.blackdown.org> archive/latest/936
X-Loop: java-linux@java.blackdown.org
Precedence: list
Resent-Sender: java-linux-request@java.blackdown.org

On Fri, 12 Jan 1996, Davide Rossi wrote:
> On Fri, 12 Jan 1996, cjs wrote:
> > There is no reason why the Java interperter couldn't put some limit on
> > the number of threads running. Creating/cloning threads, as you know,
> > is done in native stuff, so there is no reason why you couldn't keep a
> > counter of threads actually work, and return some sort of error code
> > when it reaches 32 or something sensible.
> 
> Are you crazy? a limit on the number of threads running? This could break a
> lot of programs (my own, for example ;)

I'd be surprised to see a thread implementation that didn't have *some*
limit on the number of threads that can be running simultaneously. I know
my tests of the Solaris threads package have shown that you can only have
around 2048 detached threads running at one time and even fewer undetached
threads. (A undetached thread is tracked by the thread library and must 
be 'join'ed with to retrieve its return code, an undetached thread is not 
tracked and its return code cannot be obtained).

Solaris also has the concept of a bound thread where a user level thread
is bound to a kernel thread (which is a preemptively scheduled entity) and
the limit on those is somewhere in the 256 range (this limit is equivalent
to the limit on the number of processes that a user can have). I don't see
this as being at all unreasonable since Unix has long had to deal with 
the security problem of while(1) fork();.

/o)\ mbayne@qualcomm.com
\(o/ e pluribus unix  

