Replace commit feed aggregation with manual import

This is the starting point for extending _Overview_ to support various
types of recent updates (i.e. not just blog articles and commits over a
certain message size).

While direct fetching and rendering of markdown-formatted Git commit
messages is an attractive concept, this new approach should be much more
flexible. As a side benefit commit entries can now be edited and
expanded compared to their fixed Git reference. e.g. retroactively
expanding upon older commits or adding example media that doesn't
strictly belong inside the actual commit message.

1 files changed, 11 insertions, 0 deletions

diff --git a/source/00_content/commits/change/2016_02_17_15_02_af756d78ac042a2eed2417c5250d4b675d43bf93.md b/source/00_content/commits/change/2016_02_17_15_02_af756d78ac042a2eed2417c5250d4b675d43bf93.md
new file mode 100644
index 0000000..8c81150
--- /dev/null
+++ b/source/00_content/commits/change/2016_02_17_15_02_af756d78ac042a2eed2417c5250d4b675d43bf93.md
@@ -0,0 +1,11 @@
+# Implement static allocator for initialization
+
+The previous interposition logic based on plain usage of `dlsym` analogously to various online examples led to a deadlock during _neovim_ startup. This deadlock was caused by _neovim_'s custom memory allocation library _jemalloc_ because it calls `mmap` during its initialization phase. The problem with calling `mmap` during initialization is that this already leads to executing `libChangeLog`'s `mmap` version whoes static `actual_mmap` function pointer is not initialized at this point in time. This is detected and leads to a call to `dlsym` to remedy this situation. Sadly `dlsym` in turn requires memory allocation using `calloc` which leads us back to initializing _jemalloc_ and as such to a deadlock.
+
+I first saw this as a bug in _jemalloc_ which seemed to be confirmed by a short search in my search engine of choice. This prompted me to create an appropriate [bug report](https://github.com/jemalloc/jemalloc/issues/329) which was dismissed as a problem in the way `mmap` was interposed and not as a bug in the library. Thus it seems to be accepted practice that it is not the responsibility of a custom memory allocator to cater to the initialization needs of other libraries relying on function interposition. This is of course a valid position as the whole issue is a kind of _chicken and egg_ problem where both sides can be argued.
+
+To cut to the chase I was left with the only option of working around this deadlock by adapting `libChangeLog` to call `dlsym` without relying on the wrapped application's memory allocator of choice. The most straight forward way to do this is to provide another custom memory allocator alongside the _payload_ function interpositions of `mmap` and friends.
+
+`init/alloc.cc` implements such a selectively transparent memory allocator that offers a small static buffer for usage in the context of executing `dlsym`.The choice between forwarding memory allocation requests to the wrapped application's allocator and using the static buffer is governed by `init::dlsymContext`. This tiny helper class maintains an `dlsym_level` counter by posing as a scope guard.
+
+The end result of this extension to `libChangeLog` is that it now also works with applications using _jemalloc_ such as _neovim_ and should overall be much more robust during its initialization phase.