From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <Bertrand.Jeannet@inria.fr>
X-Original-To: caml-list@sympa.inria.fr
Delivered-To: caml-list@sympa.inria.fr
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83])
	by sympa.inria.fr (Postfix) with ESMTP id 5807180026
	for <caml-list@sympa.inria.fr>; Mon, 10 Oct 2016 18:49:57 +0200 (CEST)
X-IronPort-AV: E=Sophos;i="5.31,325,1473112800"; 
   d="scan'208";a="240169780"
Received: from argosim.pro.38.cust.bluenetech.net (HELO [192.168.1.108]) ([109.197.105.43])
  by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 10 Oct 2016 18:49:57 +0200
To: =?UTF-8?Q?Fran=c3=a7ois_Bobot?= <francois.bobot@cea.fr>,
 caml-list@inria.fr
References: <57FB9441.3060703@inria.fr>
 <2eb2cf19-6ad8-ee9d-9b76-a71c0d5ed7c2@cea.fr>
From: Bertrand Jeannet <Bertrand.Jeannet@inria.fr>
Message-ID: <57FBC6B7.8020407@inria.fr>
Date: Mon, 10 Oct 2016 18:49:59 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <2eb2cf19-6ad8-ee9d-9b76-a71c0d5ed7c2@cea.fr>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [Caml-list] Ephemerons: is this behavior correct ?

Le 10/10/2016 15:38, François Bobot a écrit :
> Hi Bertrand,
>
> On 10/10/2016 15:14, Bertrand Jeannet wrote:
>> The following piece of code raises an assert false exception (in rare
>> cases) with official version 4.03.0:
>>
>> match Ephemeron.K1.get_data c with
>> | Some _ ->
>>    match Ephemeron.K1.get_key c with
>>    | Some _ -> (* ... *)
>>    | None -> assert false (* reachable *)
>  >
>> The documentation of the Ephemeron module says:
>> "When one of the keys is not considered alive anymore by the GC, the
>> data is emptied from the ephemeron"
>>
>> I was expecting this to happen atomically from the programmer point of
>> view,
> Yes, atomicity is the intent.
>
>> but here apparently the key was emptied but the data kept (at
>> least temporarily).
>
> I don't deduce that from the example. The cleaning can be done
> atomically between the return of get_data and the return of get_key
> (indeed get_key does an allocation).

Hi Francois,

Thank you for the explanation. I missed the point that a reachable data 
value does not prevent the key and the data fields to be emptied (it is 
explicitly mentioned in the documentation).

Best regards
Bertrand