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