From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 255E2BC0A for ; Sat, 2 Dec 2006 12:19:13 +0100 (CET) Received: from furbychan.cocan.org (furbychan.cocan.org [80.68.91.176]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id kB2BJ9ej018625 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 2 Dec 2006 12:19:12 +0100 Received: from rich by furbychan.cocan.org with local (Exim 3.35 #1 (Debian)) id 1GqStc-0004D6-00; Sat, 02 Dec 2006 11:19:04 +0000 Date: Sat, 2 Dec 2006 11:19:04 +0000 To: Dmitry Bely Cc: caml-list@inria.fr Subject: Re: [Caml-list] Can GC be BLOCKed? Message-ID: <20061202111904.GA16137@furbychan.cocan.org> References: <1965df800611291633q4f615df5qaa43dc967ba87d56@mail.gmail.com> <1FB91514-18D1-4502-AF67-C1003EB8636B@mac.com> <1965df800611301607g330f5517saeba25d40c3321ca@mail.gmail.com> <20061201091932.GA29517@furbychan.cocan.org> <90823c940612010539vacb2ffasf4e90748ef1c0485@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <90823c940612010539vacb2ffasf4e90748ef1c0485@mail.gmail.com> User-Agent: Mutt/1.5.9i From: Richard Jones X-Miltered: at concorde with ID 4571612D.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ocaml:01 ocaml:01 malloc:01 blog:98 blog:98 heap:01 heap:01 garbage:01 wrote:01 wrote:01 minor:01 caml-list:01 functions:01 dmitry:01 bely:01 On Fri, Dec 01, 2006 at 04:39:26PM +0300, Dmitry Bely wrote: > On 12/1/06, Richard Jones wrote: > > >I've only seen two cases where I'd want to stop the GC from running: > >(1) During quasi real-time operations (eg. a single frame in a game) -- > >this can be solved by making the heap large enough and running the GC > >at scheduled points. (2) When the heap is larger than physical RAM -- > >this is solved using our 'Ancient' module. > > I have a main program in C that periodically calls an OCaml function > and expects the (near) real time response. So I'd like to avoid gc > inside that function. My current plan is to have another OCaml thread > that is unfrozen just before returning results to C and does the minor > (or major - how to decide which one?) garbage collection. Will it > work? I guess it'll work - the thing to do is to try it. I'm wondering why you need a real time response, and I also hope you're avoiding any sort of memory allocation on the C side, because malloc and free are hardly real time functions either. Many C programmers seem to treat them as if they were O(1) operations though. Rich. -- Richard Jones, CTO Merjis Ltd. Merjis - web marketing and technology - http://merjis.com Internet Marketing and AdWords courses - http://merjis.com/courses - NEW! Merjis blog - http://blog.merjis.com - NEW!