From owner-freebsd-java Mon May 7 10:19:42 2001 Delivered-To: freebsd-java@hub.freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 554CA37B61F for ; Mon, 7 May 2001 10:19:36 -0700 (PDT) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id LAA06366; Mon, 7 May 2001 11:19:23 -0600 (MDT) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id LAA04208; Mon, 7 May 2001 11:19:19 -0600 (MDT) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15094.55574.718167.919180@nomad.yogotech.com> Date: Mon, 7 May 2001 11:19:18 -0600 (MDT) To: Jan Grant Cc: "David P. Caldwell" , freebsd-java Subject: RE: Reading and writing audio data at the same time on Linux In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-java@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > I'm not an expert on the linux JDK, but I ran into this sort of problem a > > few years back. > > > > Could it have to do with different scheduling? > > Actually, according to the java spec (as I've been led to understand it) > there is NO WAY to guarantee round-robin timesliced scheduling in java. Correct. However, there are ways that work on most any 'normal' platform. (However, it may not work on a J2ME platform that uses something like microJava, etc...) > Why? Well, your suggestion above sounds plausible: have a high-priority > thread wake up occasionally and ensure that the right priority thread is > running. But Java says that thread priorities may be mapped onto a > smaller number of priority levels that the ohst OS provides, and says > nothing about how that mapping is performed. The result is that there > seems (to me, at least) to be NO portable way of ensuring that your > MAX_PRIORITY thread is _really_ running at any higher priorituy than any > other thread, so it may never wake up. It may not be portable across *all* JVM's, but it should work on any hardware platform that supports J2SE. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message