2 ms·
So according to the article there are three approaches: - The existing implementation, which misbehaves with newer glibc - The partially-implemented patches,
by chriswarbo 10y ago
So according to the article there are three approaches:
- The existing implementation, which misbehaves with newer glibc
- The partially-implemented patches, which replace the existing core dump hacks with a big pile of C
- Some unspecified, potential future optimisations to the elisp loader
To me, that looks more like a roadmap than a dispute.
- korethr 10y agoTo me, the dispute is coming from what appears to be Zaretskii wanting nothing less than step 3. I can sympathize; I don't think I would want to receive a big pile of C were I a maintainer. It seems to me that temporary hacks tend to become permanent. However, I think he's mistaken. As you said, that list makes a decent roadmap. IMO, the best approach to hand is to take the currently offered patch, and continue to work towards specifying and implementing optimizations to the elisp loader.
- rurban 10y agoyou forgot the forth: - use your own malloc, favorably ptmalloc3. This way you are independent on glibc changes and platform quirks. It is faster, has arena support, and should have been the default glibc malloc anyway.