caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Markus Mottl" <markus.mottl@gmail.com>
To: "Hendrik Tews" <tews@tcs.inf.tu-dresden.de>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] two questions for keeping harmony (with the garbage collector)
Date: Fri, 12 May 2006 19:47:58 -0400	[thread overview]
Message-ID: <f8560b80605121647j4a238d58y6d3acb46d3e26899@mail.gmail.com> (raw)
In-Reply-To: <17509.4927.287237.266015@ithif59.inf.tu-dresden.de>

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


      reply	other threads:[~2006-05-12 23:48 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-12 22:59 Hendrik Tews
2006-05-12 23:47 ` Markus Mottl [this message]

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=f8560b80605121647j4a238d58y6d3acb46d3e26899@mail.gmail.com \
    --to=markus.mottl@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=tews@tcs.inf.tu-dresden.de \
    /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).