Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: "Dr. Thomas Fischbacher" <t.fischbacher@soton.ac.uk>
To: Markus Mottl <markus.mottl@gmail.com>
Cc: OCaml List <caml-list@yquem.inria.fr>
Subject: Re: [Caml-list] Custom blocks and finalization
Date: Wed, 6 May 2009 18:53:56 +0100	[thread overview]
Message-ID: <4A01CEB4.10907@soton.ac.uk> (raw)
In-Reply-To: <f8560b80905060954h34824bdbv5e7c42a37df0e15d@mail.gmail.com>


Markus,

> Neither of the above will ever trigger a garbage collection, but they
> are still prohibited.
So, I ask: Why? Unregistering a global root evidently does not trigger a GC,
and starting a GC from within a C-registered custom
hasher/finalizer/comparer/serializer/etc is the one specific thing that
according to the docs causes trouble, so I don't really see why I should go
through quite a fair bit of our codebase to come up with a fix to something
which as far as I can see must not be a problem.

> It certainly doesn't, but it obviously manipulates runtime
> datastructures which may not necessarily be in a state during
> finalization where this is safe.  I'd have to study the runtime code
> in detail to learn more, but maybe the OCaml team can clarify this
> issue more quickly?
>   

Yes, clarification would be much appreciated. I still maintain that my
use of caml_remove_global_root() in a finalizer is not in violation of 
this spec:

===>
  Note: the finalize, compare, hash, serialize and deserialize functions
attached to custom block descriptors must never trigger a garbage 
collection.
Within these functions, do not call any of the Caml allocation 
functions, and
do not perform a callback into Caml code. Do not use CAMLparam to 
register the
parameters to these functions, and do not use CAMLreturn to return the 
result.
<===

So, if there is a problem with this practice, it is certainly an OCaml 
bug (i.e. spec
not matching behaviour) and should be fixed by the OCaml team.

-- 
best regards,
Thomas Fischbacher
t.fischbacher@soton.ac.uk


  reply	other threads:[~2009-05-06 18:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-30 15:46 Markus Mottl
2009-04-30 18:17 ` [Caml-list] " Dr. Thomas Fischbacher
     [not found] ` <49FB04A9.3090008@soton.ac.uk>
2009-05-01 16:00   ` Markus Mottl
2009-05-06 16:30     ` Dr. Thomas Fischbacher
2009-05-06 16:54       ` Markus Mottl
2009-05-06 17:53         ` Dr. Thomas Fischbacher [this message]
2009-05-08  9:36         ` Xavier Leroy
2009-05-08 13:48           ` Markus Mottl

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=4A01CEB4.10907@soton.ac.uk \
    --to=t.fischbacher@soton.ac.uk \
    --cc=caml-list@yquem.inria.fr \
    --cc=markus.mottl@gmail.com \
    /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