Re: [Rd] serializing recordedplot object

From: Martin Morgan <>
Date: Tue, 10 Jan 2012 15:33:25 -0800

On 01/10/2012 02:54 PM, Simon Urbanek wrote:
> On Jan 10, 2012, at 4:12 PM, Jeroen Ooms wrote:
>> On Tue, Jan 10, 2012 at 6:17 AM, Simon Urbanek
>> <> wrote:
>>> Unfortunately R doesn't provide a way for this. Without changes to unserialization (on the wishlist for a few years now, but not easy to design) the best you can do is to check the native symbols for NULL pointers on usage and then re-fetch - that's something that could be done reasonably easily, although it's still a hack ...
>> Hmm that concerns me a bit. I make heavy use of saveRDS and readRDS in
>> my framework and have assumed that for all practical purposes most
>> objects can be saved to disk and loaded later on without problems. Are
>> there any other types of objects that are not being
>> serialized-unserialized to a state where they are functional again?
> No, AFAIR just external pointers (and weak references I presume).
> There is simply no way to serialize them, because by definition such
> objects are transient and only present in the running process. They
> lose meaning the moment the process is terminated.

Maybe obvious so I won't waste public bandwidth, but opened connections of all sorts (e.g., to data bases) and [to be explicit] references to c / c++ (probably many packages using Rcpp produce these) objects. Martin

>> In the case of the NativeSymbolInfo object, it should not be too hard
>> to add an optional feature to unserialize which reloads the package
>> and NativeSymbolInfo when it runs into nullpointers during
>> unserialization? I am currently doing this manually after the
>> unserialization, but that introduces quite some overhead.
> You could hard-code a special case of NativeSymbolInfo into R itself, but there are many other uses of external pointers in packages. The practical problem is that by definition you have no way of knowing which code will be able to unserialize a given external pointer. The fact that it is wrapped in a class is quite irrelevant to the pointer itself which doesn't know that. And conversely the class itself doesn't know that it may contain an external pointer - it's just a vanilla structure and you can't feasibly run a method on every single object you unserialize just to find out. Also you would need a special way of creating some raw byte stream that represents the state of the external pointer - apart from the regular serialization. That's why the current "solution" is that code using external pointers checks for NULL pointers and attempts to deal with that by inferring whether it can restore it or not from the information available (which is not always possible).
> Cheers,
> Simon
> ______________________________________________
> mailing list

Computational Biology
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109

Location: M1-B861
Telephone: 206 667-2793

______________________________________________ mailing list
Received on Tue 10 Jan 2012 - 23:39:00 GMT

This quarter's messages: by month, or sorted: [ by date ] [ by thread ] [ by subject ] [ by author ]

All messages

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Wed 11 Jan 2012 - 10:40:08 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.

list of date sections of archive