Re: concurrency suggestions for Gnus

[Lars Ingebrigtsen <larsi@gnus.org>]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Sun, 06 Feb 2011 19:34:51 -0700 Tom Tromey <tromey@redhat.com> wrote: 
>
> Tom> If we went the "lock anything" route, I would suggest a weak hash table
> Tom> for locks, instead of putting the lock into the object.
>
> A bloom filter would guarantee no false negatives, which as you noted is
> the vast majority of the cases, requires very little space per element
> (about 16 bytes to ensure max 0.1% false positives), and runs in
> constant time.

I don't really see the problem with using traditional explicit locks in
Emacs Lisp.  That's what we do over in Common Lisp World, and I think it
fits the olde-fashioney stylee of our Emacs Lisp programs well.  (What
with all our global variables and very mutable objects.)

> Here are some Gnus ideas:
>
> Rebuilding the thread tree in the summary buffer can probably be
> parallelized.  For large summaries (over 5000 articles) it can be a long
> wait.

It certainly feels like Gnus summary generation isn't linear, so I think
one should look into what Gnus is actually doing when generating the
summary buffers.  I have a feeling that there's a big exponential bug
hiding in there somewhere.

But, yes, summary generation would be a nice thing to parallelise, and
it could be segmented on thread boundaries.  Possibly.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen