Note the subject is tongue-in-cheek — I realize you can’t pickle threading.Thread and multiprocessing.Process, but for some (possibly sick) reason I want to do an implementation for both that implements __getstate__ and __setstate__ and changed the __repr__ for both to not refer to any sort of run-time state.
You don’t need to serialize the function thats passed in: the assumption here is that you’re serializing them prior to calling start() (because serializing a running thread would be awesome — in that “hey my brain just melted” sort of way).
The best (read, only sane) use case would be to allow threads/processes to be defined in say, a YAML file and generated at parse-time (the client could call .start()) or sending a blob of serialized threads to a remote client and having it call start() to act as a slave.
And that concludes the random thought for the day.
Edit: And in the comments, Ben Hayden posted a link to a version of threading.Thread which can be serialized. You can see it here. I need to make a multiprocessing.Process version of it too, just, well, cause.
-
x
-
http://www.thok.org/bloggery _Mark_
-
jnoller
-
jnoller
-
http://bob.pythonmac.org/ Bob Ippolito
-
Miguel S Filipe
-
http://code.google.com/p/benjhayden/ Ben Hayden
-
jnoller
-
jnoller
-
http://jessenoller.com jnoller