Sebastien Binet bi...@cern.ch writes:
Austin Clements amdra...@mit.edu writes:
Quoth Sebastien Binet on Jul 09 at 10:25 am:
hi there,
I was trying to reduce the I/O stress during my usual email
fetching+tagging by writing a little program using the go bindings to
notmuch.
ie:
db,
c...@webprojekty.cz writes:
I might not always have time to read the entirety of the ML, so it would
be great if people CC me when posting there.
OK, please add some kind of README file explaining the best way to
report bugs.
You can consider it public domain. I guess I should add wtfpl
Le 18/07/2012 23:40, Austin Clements a écrit :
This is subtle enough that I think it deserves a comment in the source
code explaining that tracking the talloc owner reference, combined
with the fact that Go finalizers are run in dependency order, ensures
that the C objects will always be
Well, thanks for the quick review :)
I have updated all the patches to take your fixes into account, there is
still the discussion left about the GC integration. Once we get that
sorted out, I'll send the updated version.
Le 18/07/2012 23:51, Austin Clements a écrit :
This series looks good
This method explicitly flushes the pending modifications to disk. It is
useful if your program has various threads, each with a read only DB and
one writer thread with a read/write DB. In that case, you most likely
want the writer to sync the changes to disk so that the readers can see
them,
Xapian (and therefore Notmuch? I would not mind a confirmation here) is
thread safe as long as you don't share DB instances across threads. The
database backend supports one writer and several concurrent readers.
One possible model for multi threaded apps using Notmuch is to have one
thread with a
Calling notmuch_database_reopen is needed to refresh the database
contents when the database on disk was modified by another
notmuch_database_t instance, for example in a different thread.
---
lib/database.cc | 17 +
lib/notmuch.h |8
2 files changed, 25
Quoth Adrien Bustany on Jul 19 at 9:25 pm:
Le 18/07/2012 23:40, Austin Clements a écrit :
This is subtle enough that I think it deserves a comment in the source
code explaining that tracking the talloc owner reference, combined
with the fact that Go finalizers are run in dependency order,
>>
>> Note that there is an important optimization in notmuch tag that you
>> might have to replicate. It manipulates the original query to exclude
>> messages that already have the desired tags, so that they get skipped
>> very efficiently at the earliest stage possible.
> I already have this in my original shell script.
> (wouldn't be too hard to automatically do, though.)
FYI, I've put this into a new notmuch-mtag go-based binary over here:
https://github.com/sbinet/notmuch/blob/dev/go-bindings/bindings/go/src/notmuch-mtag/main.go
-s
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20120719/4a91371d/attachment-0001.pgp>
ccx at webprojekty.cz writes:
>
> I might not always have time to read the entirety of the ML, so it would
> be great if people CC me when posting there.
>
OK, please add some kind of README file explaining the best way to
report bugs.
>
> You can consider it public domain. I guess I should add
Le 18/07/2012 23:40, Austin Clements a ?crit :
> This is subtle enough that I think it deserves a comment in the source
> code explaining that tracking the talloc owner reference, combined
> with the fact that Go finalizers are run in dependency order, ensures
> that the C objects will always be
Well, thanks for the quick review :)
I have updated all the patches to take your fixes into account, there is
still the discussion left about the GC integration. Once we get that
sorted out, I'll send the updated version.
Le 18/07/2012 23:51, Austin Clements a ?crit :
> This series looks good
This method explicitly flushes the pending modifications to disk. It is
useful if your program has various threads, each with a read only DB and
one writer thread with a read/write DB. In that case, you most likely
want the writer to sync the changes to disk so that the readers can see
them,
Xapian (and therefore Notmuch? I would not mind a confirmation here) is
thread safe as long as you don't share DB instances across threads. The
database backend supports one writer and several concurrent readers.
One possible model for multi threaded apps using Notmuch is to have one
thread with a
Calling notmuch_database_reopen is needed to refresh the database
contents when the database on disk was modified by another
notmuch_database_t instance, for example in a different thread.
---
lib/database.cc | 17 +
lib/notmuch.h |8
2 files changed, 25
15 matches
Mail list logo
