From: wmorgan-sup@masanjin.net (William Morgan)
Subject: [sup-talk] Crash while scrolling
Date: Thu, 01 Oct 2009 11:31:20 -0700 [thread overview]
Message-ID: <1254421545-sup-8303@masanjin.net> (raw)
In-Reply-To: <1254418089-sup-5800@ben-laptop>
Reformatted excerpts from Ben Gamari's message of 2009-10-01:
> It seems that C would definitely be a good start (or perhaps C++ would
> be a better idea as that is the language in which Xapian is written).
I was proposing that as a strawman argument. C does not solve my
problem.
> However, I think one of the real issues is the exclusive nature of
> index access. In fact, this is one of my primary gripes with the sup
> workflow. After processing a large number of messages, the write-out
> time can be quite substantial upon killing the buffer.
It is possible to address this in a variety of ways, many of which have
been discussed over the years, but yes, I agree that a delay is
nonideal.
> If this were the case, then we could get support for mutable sources
> for free, as we could synchronize against sources without interrupting
> workflow (although keeping the view in sync with the backend would be
> a bit tricky).
Making message state saving fast, or backgrounded, is a different beast
from scanning over a mailstore.
I have been working on a Sup server for quite some time that would
address many of these problems, but progress is slow.
> As an aside, it would be quite nice if one could run multiple
> simultaneous instances of sup. It seems that if one only held write
> access to the index during writes (is this the case presently?), there
> should be nothing preventing this from being possible.
It might be possible to do this with Xapian, especially if there were no
expectation of updates being transmitted across processes. With Ferret,
if it is possible, it's only with a tremendous amount of effort.
--
William <wmorgan-sup at masanjin.net>
next prev parent reply other threads:[~2009-10-01 18:31 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-11 16:58 Ben Gamari
2009-09-12 16:35 ` William Morgan
2009-09-13 15:02 ` Ben Gamari
2009-09-16 17:23 ` Ben Gamari
2009-09-26 14:31 ` William Morgan
2009-09-28 18:10 ` Ben Gamari
2009-10-01 13:43 ` William Morgan
2009-10-01 17:44 ` Ben Gamari
2009-10-01 18:31 ` William Morgan [this message]
2009-10-01 19:01 ` Ben Gamari
2009-10-11 20:31 ` William Morgan
2009-10-01 18:41 ` [sup-talk] Writing time-sensitive portions of sup in C Carl Worth
2009-09-30 21:21 ` [sup-talk] Crash while scrolling William Morgan
2009-10-04 19:59 ` Guillaume Quintard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1254421545-sup-8303@masanjin.net \
--to=wmorgan-sup@masanjin.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox