Version française
Home     About     Download     Resources     Contact us    
Browse thread
two questions for keeping harmony (with the garbage collector)
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Markus Mottl <markus.mottl@g...>
Subject: Re: [Caml-list] two questions for keeping harmony (with the garbage collector)
On 5/12/06, Hendrik Tews <tews@tcs.inf.tu-dresden.de> wrote:
> 1. About rule 1: CAMLparam / CAMLreturn can be ommitted in the
>    following cases:
>
>    a) there is no value in the function that is a pointer to a
>       block inside the heap.

If you do not have a pointer into the OCaml-heap (i.e. nothing of type
"value"), then there is naturally nothing to protect.  I sometimes
prefer the Begin_roots/End_roots-macros defined in memory.h if I want
to protect values allocated locally.  I always use the
CAMLparam/return macros to protect function arguments.

>    b) no allocation will take place between the start and the end
>       of the function. (Really? Even in the presence of threads?)

It depends.  If you use threads and call
"caml_{enter,leave}_blocking_section" within the function and have a
value whose lifetime extends into (e.g. I/O-operations on bigarrays)
or crosses this block, then you will have to protect this value,
because the GC may be called within the blocking section by another
thread, which might reclaim the value.  If any of the above
requirements does not hold and if you don't allocate anything before
using that value (standard case), then you don't have to protect the
value.

> 2. I believe rule 2 (register with CAMLlocal) must be extended to
>    intermediate values. Consider for instance
>
>       value f(...);
>       value g(...);
>
>       ...
>       h(f(...), g(...));
>
>    Assuming right to left evaluation, this will break if the
>    garbage collector is called inside f, because the value
>    returned by g is not registered as a root.

True, this might break.

>    However, the following is save:
>
>       h2(g(...))
>
>    because h2 will register the value before any allocation can
>    happen.

Yes, this is safe.

Regards,
Markus

-- 
Markus Mottl        http://www.ocaml.info        markus.mottl@gmail.com