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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 2DFD7BC6B for ; Tue, 12 Feb 2008 22:58:11 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.25,342,1199660400"; d="scan'208";a="7243120" Received: from yquem.inria.fr (HELO ak.bluestreak.com) ([128.93.8.37]) by mail2-relais-roc.national.inria.fr with ESMTP; 12 Feb 2008 22:58:01 +0100 Message-Id: <2350A969-FB1D-4F1A-AB97-4166C047A758@inria.fr> From: Damien Doligez To: Caml Mailing List In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [Caml-list] Using the C FFI to wrap an OCaml library Date: Tue, 12 Feb 2008 22:58:10 +0100 References: <85FB0157-5721-45F1-9440-A3021913BA1F@galois.com> <24097E85-C08E-4547-986B-4EF91B7692C3@inria.fr> <20080208.135334.126881887.jstanley@galois.com> X-Mailer: Apple Mail (2.915) X-Spam: no; 0.00; damien:01 damien:01 ffi:01 ocaml:01 ocaml:01 runtime:01 pointer:01 synchronous:01 marshaled:01 pointer:01 allocates:01 hash:01 deallocation:01 deallocation:01 doligez:01 On 2008-02-09, at 05:07, Jonathan Bryant wrote: > On Fri, Feb 8, 2008 at 4:53 PM, Joel Stanley > wrote: > >> Well, much of my curiosity stems from the fact that I know little >> about >> the OCaml runtime or how the OCaml GC is invoked. If the GC can >> ever be >> invoked in its own thread, it seems like while the values (of type >> 'value') are being passed back on the stack (but *after* the >> caml__local_roots pointer has been reverted) there could be problems? >> >> If this can't ever happen, great! Why not? > > > I believe GC cycles can only be kicked off by an allocation since > this is the only time that any memory would need to be recovered, so > this could never happen. As I understand it, any GC cycles would > start and complete within the call to the allocation function. That is true, but there is a more fundamental reason. > Multi threaded code might be an exception, because there could be a > context switch and a GC triggered by another thread at just the > wrong moment. Even if the GC was concurrent, it would have to get the roots from the worker thread's stack in an synchronous fashion, so it would be safe. On 2008-02-08, at 22:53, Joel Stanley wrote: > So let's talk about a concrete example here. Let's say that I have > some > dynamically-allocated object on the OCaml heap (for discussion > purposes, > say it's an instance of some simple 'stack' class) and that I've > returned a reference to that object to a C function. Are you saying > that the stack contents (e.g., a deep copy of my object) themselves > are > marshaled across this boundary every time? No, it's just a pointer, and if your C function allocates in the OCaml heap, you'd better declare that pointer as a root and make sure you reread it after each time it could have moved. > What about, perhaps, having an object registration mechanism on the > OCaml so that a newly-allocated object's reference goes into a > (global) > hash table, and an opaque handle (e.g., some fresh, unique integer > value) is yielded back to C land? This would require an explicit > deallocation (just passing the handle back) to come from the C side, > but > should keep the heap object around until such a deallocation call is > made. Right? This is pretty much what caml_register_global_root and caml_remove_global_root do, except that the handle isn't opaque. -- Damien