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=1.3 required=5.0 tests=AWL,HTML_MESSAGE,SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 0514BBC6C for ; Sat, 9 Feb 2008 05:07:58 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAALq1rEdIDtyfkmdsb2JhbACCOzaNRAEBAQEHBAQTFpJEhW4 X-IronPort-AV: E=Sophos;i="4.25,325,1199660400"; d="scan'208";a="22423149" Received: from fg-out-1718.google.com ([72.14.220.159]) by mail4-smtp-sop.national.inria.fr with ESMTP; 09 Feb 2008 05:07:57 +0100 Received: by fg-out-1718.google.com with SMTP id l27so4015431fgb.43 for ; Fri, 08 Feb 2008 20:07:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=a9Rk3eKKeeLJHkI1rJGbD+5AJLqv5GSWrFWa0kRNgVg=; b=MV7EydxFEzLfFbQj2V74XVnNCNN0kzXMGY5lNQrHW79Naim6pKIqNBtanw6ckTc4N3t4TMdFkfXCls3M7eqSi0jborXkkVsWjeuwuoeGgz4ChwcQMWjLkrcP8OAcxZtrD6Q2mlLnlRfcjdSQYPOKKcElNXYEVMcXp6G/+0UrpP0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=pEQsP1plWuEV6fpzTVpYxvUiEk2s1fMPv8nD0zAqtvMXlRkwIMj3Sts62kTJdeFji7zINKo3KyDsCKN0R3b32B6EiszdbNPYRsHQDw83YOo6FHAT9SRxlkZyZPPyvp3ewkX0dom5lKo5yHltgYW36CHDQZf4u1XqmxBAdgYaC6k= Received: by 10.86.87.5 with SMTP id k5mr12440900fgb.51.1202530077120; Fri, 08 Feb 2008 20:07:57 -0800 (PST) Received: by 10.86.52.20 with HTTP; Fri, 8 Feb 2008 20:07:57 -0800 (PST) Message-ID: Date: Fri, 8 Feb 2008 23:07:57 -0500 From: "Jonathan Bryant" Sender: watersofmemory@gmail.com To: "Joel Stanley" Subject: Re: [Caml-list] Using the C FFI to wrap an OCaml library Cc: "Caml Mailing List" In-Reply-To: <20080208.135334.126881887.jstanley@galois.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_14929_17486715.1202530077107" References: <85FB0157-5721-45F1-9440-A3021913BA1F@galois.com> <24097E85-C08E-4547-986B-4EF91B7692C3@inria.fr> <20080208.135334.126881887.jstanley@galois.com> X-Google-Sender-Auth: 7873dc21c8f03c02 X-Spam: no; 0.00; ffi:01 ocaml:01 ocaml:01 runtime:01 pointer:01 runtime:01 pointer:01 wrote:01 wrote:01 stack:01 stack:01 exception:01 exception:01 caml-list:01 caml:02 ------=_Part_14929_17486715.1202530077107 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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. 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. --Jonathan ------=_Part_14929_17486715.1202530077107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Fri, Feb 8, 2008 at 4:53 PM, Joel Stanley <jstanley@galois.com> 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.  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.

--Jonathan

------=_Part_14929_17486715.1202530077107--