Received: from SOUTH-STATION-ANNEX.MIT.EDU by po7.MIT.EDU (5.61/4.7) id AA00725; Fri, 12 Jan 96 18:51:16 EST
Received: from liquor.cabi.net by MIT.EDU with SMTP
	id AA27900; Fri, 12 Jan 96 18:51:17 EST
Received: (from listadm@localhost) by liquor.cabi.net (8.6.12/8.6.12) id SAA11333; Fri, 12 Jan 1996 18:51:28 -0500
Resent-Date: Fri, 12 Jan 1996 18:51:28 -0500
Date: Fri, 12 Jan 1996 23:35:18 +0100 (MET)
From: Davide Rossi <rossi@cs.unibo.it>
X-Sender: rossi@despina
To: cjs <cjs@netcom.com>
Cc: John Sigler <jsigler@spdmail.spd.dsccc.com>, chapman@u.washington.edu,
        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.960112233124.2004A-100000@despina>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Resent-Message-Id: <"VvmIP2.0.Om2.SFlzm"@liquor>
Resent-From: java-linux@java.blackdown.org
X-Mailing-List: <java-linux@java.blackdown.org> archive/latest/935
X-Loop: java-linux@java.blackdown.org
Precedence: list
Resent-Sender: java-linux-request@java.blackdown.org



On Fri, 12 Jan 1996, cjs wrote:

> > On January 11, Randy Chapman wrote:
> > 
> > > On Linux, as on Solaris (and on the Mac), Java is strictly one process 
> > > using a completely user level threading implementation.  This means,
> > >
> > > ...
> > >
> > > A simplistic linux kernel-based threads approach, otoh, would have each
> > > thread in what, as far as the time-slicer is concerned, is a separate
> > > task, thus each thread of the 3threaded app having the same priority
> > > as a full single-threaded app.  Needless to say, this would allow some
> > > nasty clone/thread bombs in java, hence why I dont like this idea =(
> 
> 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.

Are you crazy? a limit on the number of threads running? This could break a
lot of programs (my own, for example ;)

> 
> As alan cox says, there are lots of reasons why the kernel threads are
> better then the user mode threads. 1) the threads take advantage of
> kernels with SMP support, 2) the kernel threads will keep functioning
> even if one thread is blocked doing disk i/o, paging, or some other
> function that normally cannot be done in a non-blocking fashion. 3)
> kernel mode threads have less context switching overhead then user
> mode threads.

Right, but we don't have kernel threads on a release version, as of now.

> 
> > Sorry if this is a bit off the normal topic but I'd really like to be
> > clear on this. Linux has only user mode threads currently, right? Is
> > someone is working on kernel mode threads, and if so, does anyone know
> > the status? Also I thought Solaris had kernel mode threads? The first
> > sentence above seems to say otherwise?
> 
> Linux's kernel threads appeared sometime in 1.3.x. Now all processes are
> actually kernel threads, and the same kernel function creates them all.
> 
Solaris has kernel mode threads. I went to a meeting by Sun here in Italy
and they said they have such a beast (and light-weight processes...).

BTW: where the development list is? I posted here since this is the onlylist
I'm aware of ;)

Ciao,
	Davide.

