From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105])
	by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q2MCq5ZV003538
	for <caml-list@sympa-roc.inria.fr>; Thu, 22 Mar 2012 13:52:05 +0100
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtACAJYfa0/B/BfUlGdsb2JhbAAqGoMOtEgBAQEBCQsJCRQDJIIJAQEFOEABEAsYCRYPCQMCAQIBRQYNAQcBAYgKBym4J5BkBJVfhW2NIw
X-IronPort-AV: E=Sophos;i="4.73,630,1325458800"; 
   d="scan'208";a="137256368"
Received: from msa03.smtpout.orange.fr (HELO msa.smtpout.orange.fr) ([193.252.23.212])
  by mail4-smtp-sop.national.inria.fr with ESMTP; 22 Mar 2012 13:51:59 +0100
Received: from [192.168.1.105] ([86.195.0.116])
	by mwinf5d61 with ME
	id ocrw1i00A2WAD4N03crx2i; Thu, 22 Mar 2012 13:51:59 +0100
Message-ID: <4F6B206D.6030103@frisch.fr>
Date: Thu, 22 Mar 2012 13:51:57 +0100
From: Alain Frisch <alain@frisch.fr>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "Richard W.M. Jones" <rich@annexia.org>
CC: caml-list@inria.fr
References: <20120322114710.GA21740@annexia.org>
In-Reply-To: <20120322114710.GA21740@annexia.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Caml-list] Native dynlink and reloading modules

On 03/22/2012 12:47 PM, Richard W.M. Jones wrote:
>
> I'm a bit surprised to find that native dynlink doesn't work in the
> same way as bytecode dynlink in respect to reloading the same module.
> (See attached test program)
>
> In bytecode dynlink, reloading (ie. Dynlink.loadfile) the same module
> causes the new module code to override the old module code:
>
>    $ ./dynlink_test
>    testing bytecode ...
>    a
>    b
>
> But in native dynlink, the new module is silently discarded and the
> old code appears to run:
>
>    $ ./dynlink_test
>    testing native ...
>    a
>    a
>
> I would classify this as a bug, but I'm not quite sure what is
> expected to happen.  Is there some other way to override a module as
> in bytecode?

natdynlink currenlty depends on the OS dynamic linker, we cannot control 
the semantics so precisely (you can try loadfile_private, but I'm not 
sure it would solve your issue). Note that doing Dynlink.loadfile 
several times on the same module name can break the soundness of the 
type system (if you change the implementation while keeping the same 
interface):

   http://caml.inria.fr/mantis/view.php?id=4229


So it's probably a bad idea anyway.

-- Alain