From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104])
	by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p36FKeWW005031
	for <caml-list@sympa-roc.inria.fr>; Wed, 6 Apr 2011 17:20:40 +0200
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmICAIqDnE3ZSMDjkWdsb2JhbACldxQBAQEBCQsLBxQDIoh5uGuFbASMF4UIgzo
X-IronPort-AV: E=Sophos;i="4.63,310,1299452400"; 
   d="scan'208";a="80324359"
Received: from fmmailgate02.web.de ([217.72.192.227])
  by mail3-smtp-sop.national.inria.fr with ESMTP; 06 Apr 2011 17:20:35 +0200
Received:  from smtp03.web.de  ( [172.20.0.65])
	by fmmailgate02.web.de (Postfix) with ESMTP id 0550119BE3941;
	Wed,  6 Apr 2011 17:20:35 +0200 (CEST)
Received: from [78.43.204.177] (helo=frosties.localnet)
	by smtp03.web.de with asmtp (TLSv1:AES256-SHA:256)
	(WEB.DE 4.110 #2)
	id 1Q7UX4-0006ok-00; Wed, 06 Apr 2011 17:20:34 +0200
Received: from mrvn by frosties.localnet with local (Exim 4.72)
	(envelope-from <goswin-v-b@web.de>)
	id 1Q7UX4-0002mp-Gl; Wed, 06 Apr 2011 17:20:34 +0200
From: Goswin von Brederlow <goswin-v-b@web.de>
To: Pedro Borges <pdhb.lists@gmail.com>
Cc: caml-list@inria.fr
References: <BANLkTin4PqRfVncz1r+JquTr9zYJXGi_+g@mail.gmail.com>
Date: Wed, 06 Apr 2011 17:20:34 +0200
In-Reply-To: <BANLkTin4PqRfVncz1r+JquTr9zYJXGi_+g@mail.gmail.com> (Pedro
	Borges's message of "Tue, 5 Apr 2011 18:10:39 +0100")
Message-ID: <87ipurbe4d.fsf@frosties.localnet>
User-Agent: Gnus/5.110009 (No Gnus v0.9) XEmacs/21.4.22 (linux, no MULE)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: goswin-v-b@web.de
X-Sender: goswin-v-b@web.de
X-Provags-ID: V01U2FsdGVkX1+v+Jr0UznOfHeRSNWoK8JIzayWg1AQZ8yMLA5A
	q/rmvzRWTSCqjJSSR7DLl4ejvQx5vgniGb1+Ou2I+nFkZxhs1U
	il5pltX84=
Subject: Re: [Caml-list] Long running finalizers and global lock

Pedro Borges <pdhb.lists@gmail.com> writes:

> Hi again,
>
> the reference manual states:
>
>  > 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.
>
> I have a long running function inse a finalizer is it safe to release
> and acquire the runtime lock ?
>
> Best Regards

If you release the lock then any ocaml values might get relocated by the
GC at any time and then your code would reference the wrong address. If
your code uses any ocaml values (CAMLparam or CAMLlocal or registered
roots) you will need to aquire the lock every time you access
them.

On the other hand I'm not sure it is allowed to release the lock in a
finalizer. Given the warning the GC seems to be in an inconsitent state
when the finalizer is run and releasing the lock would mean some other
thread would certinly allocate something and crash your program.

So overall I consider it highly unlikely. Say I'm 99% sure you can't
release the lock but I would be happy to be tought otherwise.

MfG
        Goswin