[Caml-list] Re: Closure marshalling inconsistency

[Caml-list] Re: Closure marshalling inconsistency

[oleg]

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.

Re: [Caml-list] Re: Closure marshalling inconsistency

[rossberg]

Oleg wrote:
>
> 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.

True, but I think Lauri complains about a slightly different issue, namely
sharing inconsistencies between a _single_ marshalled value and the program
environment. Or in other words, that the language does not actually define
what it means to be "_within_ a serialized values", nor implements it
consistently.

There are obvious ways in which this could be made coherent, but they are
likely to be difficult to implement as an afterthought.

> 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.

He he. That sounds like an entirely un-MLish kind of argument. The language
has undefined and incoherent semantics? Of course, it's the programmer's
mistake to expect otherwise! ;)

/Andreas