Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: oleg@okmij.org
To: la@iki.fi
Cc: caml-list@inria.fr
Subject: [Caml-list] Re: Closure marshalling inconsistency
Date: Thu, 10 Feb 2011 01:50:43 -0800 (PST)	[thread overview]
Message-ID: <20110210095043.E9EE817196@Adric.ern.nps.edu> (raw)


Lauri Alanko wrote:
> Marshalling closures with references to globals is precarious
> business.

Indeed. I would not blame OCaml though: OCaml serialization functions
(when invoked with the right flags) ensure the preservation of sharing
of components _within_ a serialized value. There are no guarantees
about the preservation of sharing _between_ separately serialized
values. The documentation explicitly says so: ``Sharing between values
marshaled by successive calls to Marshal.to_channel is not detected,
though.''  That is, if v1 and v2 share a component, the results of
pickling/unpickling v1 and separately v2 may not share the component.


If the preservation of that sharing is important, one could either
serialize v1 and v2 together (that is, serialize the pair (v1,v2)), or
declare the component whose sharing is important to be serialized by
reference. The delimited control library delimcc provides the latter
facility. It is used internally for serializing captured delimited
continuations (which contain many closures, some containing important
data whose sharing must be preserved). The facility can be used
outside of delimcc. It consists of two functions, relativitize and
absolutize, to call before serialization (resp, after deserialization)
and the facility to declare the data whose sharing is to be preserved
across separate serializations.

The (long) title comments in the file delimcc.ml (the implementation
of the delimcc library) describe this facility in detail.

> Since the environment is marshalled by value and code is marshalled by
> reference, this again makes an observable difference. I'd consider
> this a bug.

I might agree that this is a bug -- but not that it is a bug in
OCaml. I might agree with the argument that it is a global mutable
variable that is the bug, in programmer's code. Once we have
serialization, we are smack in the realm of distributed computing. The
notion of a _global_ variable becomes ill-defined. So called global
mutable variables have always been evil; they become even more so in
the distributed environment.




             reply	other threads:[~2011-02-10  9:54 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-10  9:50 oleg [this message]
2011-02-10 10:43 ` rossberg

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=20110210095043.E9EE817196@Adric.ern.nps.edu \
    --to=oleg@okmij.org \
    --cc=caml-list@inria.fr \
    --cc=la@iki.fi \
    /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