I\'m doing a fair amount of parallel processing in Python using the multiprocessing module. I know certain objects CAN be pickle (thus passed as arguments in multi-p) and other
I'm the dill
author. There's a fairly comprehensive list of what pickles and what doesn't as part of dill
. It can be run per version of Python 2.5–3.4, and adjusted for what pickles with dill
or what pickles with pickle
by changing one flag. See here and here.
The root of the rules for what pickles is (off the top of my head):
__main__
versus an imported function)? [Then, yes]__getstate__
and __setstate__
rule exist for the given object type? [Then, yes]Frame
object (i.e. rely on the GIL and global execution stack)? Iterators are now an exception to this, by "replaying" the iterator on unpickling. [Then, no] __init__
path manipulations)? [Then, no]So, (5) is less prevalent now than it used to be, but still has some lasting effects in the language for pickle
. dill
, for the most part, removes (1), (2), and (5) – but is still fairly effected by (3) and (4).
I might be forgetting something else, but I think in general those are the underlying rules.
Certain modules like multiprocessing
register some objects that are important for their functioning. dill
registers the majority of objects in the language.
The dill
fork of multiprocessing
is required because multiprocessing
uses cPickle
, and dill
can only augment the pure-Python pickling registry. You could, if you have the patience, go through all the relevant copy_reg
functions in dill
, and apply them to the cPickle
module and you'd get a much more pickle-capable multiprocessing
. I've found a simple (read: one liner) way to do this for pickle
, but not cPickle
.