[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: concurrency suggestions for Gnus

From: Lars Ingebrigtsen
Subject: Re: concurrency suggestions for Gnus
Date: Thu, 10 Feb 2011 00:17:52 -0800
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux)

Ted Zlatanov <address@hidden> writes:

> On Sun, 06 Feb 2011 19:34:51 -0700 Tom Tromey <address@hidden> 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.)
  address@hidden * Lars Magne Ingebrigtsen

reply via email to

[Prev in Thread] Current Thread [Next in Thread]