--- a/website/idxthreads/threadingRecoll.txt
+++ b/website/idxthreads/threadingRecoll.txt
@@ -2,6 +2,15 @@
:Author: Jean-François Dockès
:Email: jfd@recoll.org
:Date: 2012-12-03
+
+== Abstract
+
+This relates lessons learned while modifying *Recoll* indexing to be
+multithreaded. I am by no means a threaded applications expert, so that a
+few of the observations I made whole doing this may be of use to other
+novices.
+
+== Introduction
http://www.recoll.org[*Recoll*] is a document indexing application, it
allows you to find documents by specifying search terms.
@@ -369,8 +378,9 @@
created the filter. But the filter would often be reused by a different
thread, with the consequence that the configuration object was now accessed
and modified by two unsynchronized threads... Resetting the config pointer
-at the time of filter reuse was the ridiculously simple single-line fix to
-this evasive problem.
+at the time of filter reuse was the
+https://bitbucket.org/medoc/recoll/commits/943de4b78818079b0eb6ffd0fcbdfdd0746b4a40[ridiculously
+simple (almost)single-line fix] to this evasive problem.
Looking at multi-threaded stack dumps is mostly fun for people with several
heads, which is unfortunately not my case, so I was quite elated when this