Resent-Date: Fri, 12 Jan 1996 21:25:04 -0500
Date: Fri, 12 Jan 1996 21:23:17 -0500 (EST)
From: giles <giles@vnet.net>
To: java-linux@java.blackdown.org
Subject: Re: Threads and time quantum
In-Reply-To: <199601121621.IAA05655@netcom20.netcom.com>
Message-Id: <Pine.SUN.3.91.960112211902.25176A-100000@lys.vnet.net>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Resent-Message-Id: <"ae8CQ2.0.aM3.-Unzm"@liquor>
Resent-From: java-linux@java.blackdown.org
Precedence: list
Resent-Sender: java-linux-request@java.blackdown.org


> Randy:
> 
> 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.
>
A question on this ongoing debate. I am writing a program to learn multi-threadsand have a few questions/observations.

Non-preempting threads are a pain. Having them different on operating systems
is even more of a pain.  If I assume non-preempting and use the yield or sleep
commands will this muck things up for other OS's?  

Also, I have a system design which could "easily" reach 100's of threads. Is
this a particular bad design? I thought the big web server machines handled
this load all the time. The app I am writing would run in this environment.

Hopefully a useful round of discussion...