-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve frame and traceback pickling #107
Comments
Original comment by Anselm Kruis (Bitbucket: akruis, GitHub: akruis): I created two pull requests:
|
Original comment by Kristján Valur Jónsson (Bitbucket: krisvale, GitHub: kristjanvalur): I know that all of this was sort of discussed three years ago, in issue #62, but. |
Original comment by Anselm Kruis (Bitbucket: akruis, GitHub: akruis): @krisvale I agree with you to not over-complicate things. But recursive frame pickling breaks code, that is in productive usage at our customers. Initially I proposed recursive frame pickling, but it didn't work out. The problem is not unpickling, the problem is pickling: recursive frame pickling pickles more frames and if one of the additional frames refers an unpickleable object, pickling fails. Therefore there are two options:
I'm not completely up to date with respect to the latest developments of async methods in C-Python 3.x, but I assume, that C-Python will add some pickling support for async code sooner or later. Then it would be better not to get in the way. Therefore I'm in favour of the second option. |
Original comment by Kristján Valur Jónsson (Bitbucket: krisvale, GitHub: kristjanvalur): Right, I understand. Unpicklable things are annoying. |
Original comment by Anselm Kruis (Bitbucket: akruis, GitHub: akruis): During my work on issue #127 I wrote tests for copy.copy(). They failed for gernerator and traceback objects, because their __setstate__() method (in _stackless._wrap....) received a _FrameWrapper-object instead of a frame-object. This happens, because copy.copy() creates a shallow copy. As a consequence I modified the setstate-methods to accept a _FrameWrapper object as an alternative to a frame-object. Change is 54d3428. |
Original comment by Anselm Kruis (Bitbucket: akruis, GitHub: akruis): Final commits for part 1 (frame.f_back linkage in unpickled tracebacks) are:
Branch 3.5-slp didn't exists then. Final commits for part 2 (disable frame pickling) are:
Currently the branch default-slp is behind 3.5-slp. Therefore it is not yet possible to merge eff69deacad2 into default-slp. |
…d traceback objects __setstate__ must accept the state returned by __reduce__. This was not the case for generator and trace-back objects. This commit fixes this. The next commit (merge of issue #127) adds the relevant test cases. Additionally amends changelog.txt. https://bitbucket.org/stackless-dev/stackless/issues/107
Originally reported by: Anselm Kruis (Bitbucket: akruis, GitHub: akruis)
Issue #62 discusses problems caused by the non recursive pickling of frames. In the end I closed #62 as "won't fix", because the proposed solution (recursive frame pickling) had compatibility problems.
But there is still room for improvements:
Linkage of frames in unpickled tracebacks. It is fairly simple to reconstruct the linkage for the inner frames - as returned by inspect.getinnerframes(tb) - of a traceback. I already coded a test case and a patch to
static PyObject * tb_setstate(PyObject *self, PyObject *args)
in prickelpit.c. This could go into 2.7-slp, because it shouldn't cause any compatibility problems.In issue pickling of frames without a tasklet #62 we discussed the idea of a FrameReducer, that would avoid the requirement to add a reduce function for frames to copy_reg. See https://bitbucket.org/stackless-dev/stackless/issues/62/pickling-of-frames-without-a-tasklet#comment-10422733. I'll try to implement this proposal. I'm undecided, if this is a feature for 2.7-slp, but if it works well, it should definitely go into 3.4-slp. And it will help to fix 3.5-slp.
The text was updated successfully, but these errors were encountered: