Resent-Date: Sat, 13 Jan 1996 19:55:01 -0500
Date: Sat, 13 Jan 1996 17:30:03 -0500
Message-Id: <199601132230.RAA00365@placebo.pc.cs.cmu.edu>
From: Nick Thompson <nix+@cs.cmu.edu>
To: cjs@netcom.com
Cc: java-linux@java.blackdown.org
Subject: Re: Threads and time quantum
In-Reply-To: <199601121621.IAA05655@netcom20.netcom.com>
References: <9601121457.AA01598@sun1225.spd.dsccc.com>
	<199601121621.IAA05655@netcom20.netcom.com>
Resent-Message-Id: <"jNk5X1.0.MG5.1F5-m"@liquor>
Resent-From: java-linux@java.blackdown.org
Precedence: list
Resent-Sender: java-linux-request@java.blackdown.org

> There is no reason why the Java interperter couldn't put some limit on
> the number of threads running.

except that it would cripple the system.  any useful thread system
should allow > 1000 threads, which is more than enough to mess up
other applications if the scheduler is broken.  i don't think there's
any excuse for hardcoded resource limits in the 1990's, and the only
long-term answer to clone bombs is to fix the scheduler.

> 3) kernel mode threads have less context switching overhead then user
> mode threads.

this shouldn't be true if the user thread implementation is good.
multiple user threads within one kernel thread share more context than
two kernel threads do, by definition.  this is why there are hybrid
kernel/user thread systems that schedule a large number of user
threads using a smaller number of kernel threads.  of course, until
java is running at native code speed the performance hit of kernel
threads is insignificant anyway.

	nick