Closed IainNZ closed 8 years ago
@IainNZ @yuyichao thanks - yes, this will not work on 0.5. I guess the views on 0.5 are fast enough now that I can get rid of these tricks? I will try to fix this in the coming days - or is there any immediate urgency? than I can try to fix it tomorrow.
@IainNZ shall I rather retag the packages so that they only show up on 0.4? currently I do not test my packages on 0.5, yet.
FYI, that code is guaranteed to cause segfault one way or another on 0.3 and 0.4 too. You may not have seen that because the GC is rather forgiving.
@yuyichao ic, thanks. I take care that all pointers are always valid (I do not pass these views around), then it seemed fine to me, never got any problems (this stuff is heavily used in all my packages).
But 0.5 marks these array-internals read-only, so I will switch to the built-in views, that is much cleaner of course.
Whether the pointer is still valid is not the biggest problem.
The runtime keep track of how each arrays are allocated and will use that to determine how the array is going to be freed. Overriding the pointer will basically break all kinds of assumptions there. On 0.4, the generational GC also add more assumptions of the owner of the buffer and you could trigger really wierd segfaults in certain conditions if you break the GC invariance.
But 0.5 marks these array-internals read-only,
I'm not sure what do you mean by this. Nothing have changed for array internals on 0.5 yet AFAIK and these fields are never exposed to julia. They are also never read-only but should not be directly manipulated directly in julia code in any way.
See https://github.com/JuliaLang/julia/issues/14021 for description, and it looks like @yuyichao identified cause too