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