From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA16022; Wed, 4 Sep 2002 15:01:55 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id PAA16033 for ; Wed, 4 Sep 2002 15:01:54 +0200 (MET DST) Received: from fichte.ai.univie.ac.at (fichte.ai.univie.ac.at [131.130.174.156]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g84D1r921873 for ; Wed, 4 Sep 2002 15:01:53 +0200 (MET DST) Received: from kiefer.ai.univie.ac.at (markus@kiefer.ai.univie.ac.at [131.130.174.157]) by fichte.ai.univie.ac.at (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id PAA08235; Wed, 4 Sep 2002 15:01:52 +0200 Received: (from markus@localhost) by kiefer.ai.univie.ac.at (8.12.3/8.12.3/Debian -4) id g84D1pct003555; Wed, 4 Sep 2002 15:01:51 +0200 Date: Wed, 4 Sep 2002 15:01:51 +0200 From: Markus Mottl To: Jacques Garrigue Cc: caml-list@inria.fr Subject: Re: [Caml-list] Native threads under Debian 3.0r0 Message-ID: <20020904130151.GB1375@kiefer.ai.univie.ac.at> Mail-Followup-To: Jacques Garrigue , caml-list@inria.fr References: <20020903230314.GA311@gogol> <20020904094432.GA1375@kiefer.ai.univie.ac.at> <20020904191523M.garrigue@kurims.kyoto-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020904191523M.garrigue@kurims.kyoto-u.ac.jp> User-Agent: Mutt/1.4i Organization: Austrian Research Institute for Artificial Intelligence Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Wed, 04 Sep 2002, Jacques Garrigue wrote: > In bytecode "something_to_do" is used, and checked pretty often: > at every function call and every loop iteration. Ok. > However, this would mean too much overhead for native code, so switching > is only checked when the GC is called. Actually, calling the GC manually does not make any difference. The only thing that helps is calling "Thread.yield" in the infinite loop. > To make it work even on slowly allocating programs, the young generation > is declared "full" every once in a while, but there must still be some > allocation for it to happen. I see. So if the GC doesn't really have to do any work, it will also not switch threads even when called manually. > So the answer is: a native code thread should be allocating some data, > otherwise it cannot be interrupted. The problem does not exist for > bytecode. The main consideration is obviously native code performance. OTOH, some people might want to guarantee that their threads never get stuck. I don't know what solution would be useful for them. Maybe some runtime or command-line switch that trades efficiency against such scheduling problems. Regards, Markus Mottl -- Markus Mottl markus@oefai.at Austrian Research Institute for Artificial Intelligence http://www.oefai.at/~markus ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners