caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: skaller <skaller@users.sourceforge.net>
To: Hendrik Tews <H.Tews@cs.ru.nl>
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Interfacing with C question...
Date: Fri, 26 Jan 2007 05:29:55 +1100	[thread overview]
Message-ID: <1169749795.5333.17.camel@rosella.wigram> (raw)
In-Reply-To: <wwu4pqfrs29.fsf@tandem.cs.ru.nl>

On Thu, 2007-01-25 at 17:26 +0100, Hendrik Tews wrote:
> "David Allsopp" <dra-news@metastack.com> writes:
> 
>    Sorry if this an RADBOTFM case. 

> And you cannot use CAMLlocal or
> register_global_root, 

FWIW: I encourage people not to just use the high level macros
like CAMLlocal: they hide what really happens.

Instead, read the section describing the lower level macros
and figure out how the gc *actually* works.

Roughly speaking the rules are:

(a) certain operations, including allocation, trigger the gc.

(b) you must ensure allocated store is initialised when
the gc is triggered (so it doesn't chase off into the wild
blue yonder)

(c) you may not retain copies of values in stores across
calls that trigger the gc because it may move blocks and
adjust pointers

(d) there are some exceptions: if the value is an integer
or unboxed float it won't change (obviously).

(e) Every allocated block you want to use must be reachable
from a root when the gc is triggered

The high level macros reduce thinking by making variables
a root and ensuring they're initialised, however they're
conservative and may incur a performance overhead by doing
this when it isn't necessary. For any kind of serious glue
logic you really need to understand the low level requirements,
in particular the fact stuff moves means you have to know
precisely when the gc is triggered anyhow -- since you can't
write C without temporary creation and sequence points
being considered.

It takes a bit of reading, thinking, and question asking
to figure the gc out, but it is worth it: it really isn't that
hard and IMHO the higher level macros just confuse things
by obscuring the real constraints.

[Once you know how it works .. *then* you can use the
higher level macros because you then know what they're
sugar for .. :]

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net


  reply	other threads:[~2007-01-25 18:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-24 17:23 David Allsopp
2007-01-25  6:27 ` [Caml-list] " Remi Vanicat
2007-01-25 16:26 ` Hendrik Tews
2007-01-25 18:29   ` skaller [this message]
2007-01-26  0:16     ` Robert Roessler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1169749795.5333.17.camel@rosella.wigram \
    --to=skaller@users.sourceforge.net \
    --cc=H.Tews@cs.ru.nl \
    --cc=caml-list@yquem.inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).