From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id D80F2BB9A; Sat, 29 Oct 2005 17:22:44 +0200 (CEST) Received: from ash25e.internode.on.net (ash25e.internode.on.net [203.16.214.182]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j9TFMgeh010554; Sat, 29 Oct 2005 17:22:43 +0200 Received: from rosella (ppp7-104.lns1.syd7.internode.on.net [59.167.7.104]) by ash25e.internode.on.net (8.12.9/8.12.6) with ESMTP id j9TFMKTM084926; Sun, 30 Oct 2005 00:52:21 +0930 (CST) (envelope-from skaller@users.sourceforge.net) Subject: Re: [Caml-list] The Bytecode Interpreter... From: skaller To: Gerd Stolpmann Cc: Jonathan Roewen , caml-list@yquem.inria.fr, Damien Doligez In-Reply-To: <1130585342.15589.124.camel@localhost.localdomain> References: <5636A978-D095-489D-A20D-8E762F133240@inria.fr> <1130585342.15589.124.camel@localhost.localdomain> Content-Type: text/plain Date: Sun, 30 Oct 2005 01:22:20 +1000 Message-Id: <1130599340.7560.107.camel@rosella> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 436393C2.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 bytecode:01 gerd:01 stolpmann:01 threads:01 scheduler:01 allocates:01 stack:01 stack:01 synchronous:01 ...:98 interrupts:98 wrote:01 sourceforge:01 imho:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 On Sat, 2005-10-29 at 13:29 +0200, Gerd Stolpmann wrote: > > Also, would it be safe to build an ISR framework > > that could wake up a thread waiting on an interrupt to be triggered? > > The problem is you need realtime behaviour. That means your ISR thread > must have a higher priority than other threads, i.e. you need a > realtime-aware scheduler. > > Second, also memory management must be realtime-aware. This is the > difficult part. How to handle the case when the interrupt occurs within > a GC cycle? The easy way of course: forget about it :) ISR code only allocates memory on the stack, and it only accesses its local stack and global variables. All the real work is done by the kernel, not in the ISRs .. and the kernel is a single synchronous thread. Your main problem, IMHO, will be concurrency, not interrupts. That is -- multiprocessor support. Because typical multiprocessor OS shares a lot more data between CPUs, and runs at least part of the kernel on ALL the CPUs. -- John Skaller Felix, successor to C++: http://felix.sf.net