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
<simon.urba...@r-project.org> 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
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Computational Biology
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109
Location: M1-B861
Telephone: 206 667-2793
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
