From owner-freebsd-java Sun Feb 1 22:36:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA11596 for java-outgoing; Sun, 1 Feb 1998 22:36:54 -0800 (PST) (envelope-from owner-freebsd-java@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA11587 for ; Sun, 1 Feb 1998 22:36:51 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id XAA12376; Sun, 1 Feb 1998 23:36:23 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id XAA26813; Sun, 1 Feb 1998 23:36:21 -0700 Date: Sun, 1 Feb 1998 23:36:21 -0700 Message-Id: <199802020636.XAA26813@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: John Birrell Cc: nate@mt.sri.com (Nate Williams), SSANKARA.IN.oracle.com.ofcmail@in.oracle.com, freebsd-java@FreeBSD.ORG Subject: Re: TimeSlicing in JVM In-Reply-To: <199802020633.RAA00645@cimlogic.com.au> References: <199802020605.XAA26684@mt.sri.com> <199802020633.RAA00645@cimlogic.com.au> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe java" > > One of the really nasty things in the current green-thread port which > > exists on all *nix platforms which don't use kernel threads is that a > > single thread can sit in a tight loop and never let go, which means that > > if you have one errant thread your entire VM is hosed. This is a *bad* > > thing, but I don't see any way around it w/out kernel support. > > That's not quite true 8-) in all cases. By leaving a timer running, a > thread running in a tight loop can be interrupted by a SIGVTALRM and the > user-thread kernel can schedule another thread. libc_r does this. I'm with you so far. :) > So tight loops or thread-hogs are OK provided that the thread doesn't > hand on to locked resources. And here-in lies the rub. Doing this while avoiding races and deadlocks in 'the hard thing'. But, now that I've given it more than a nano-cycle in my brain, it's probably not any harder than doing this sort of thing with kernel threads, since they also get scheduled while holding onto locks and such, so this problem must already be solved for the most part inside of the JDK sources. So, the moral of the story is to listen to John. He knows what he's talking about! > It's non-blocking syscalls that end in tears. *grin* I also remember thinking seriously about this problem after reading a Java threads book, and they brought up another point that I can't recall right now that was also one of those 'syscall' types of problems. If I remember or find it I'll send something to the list. Nate