From: Jameson Graef Rollins <jrollins@finestructure.net>
To: Notmuch Mail <notmuch@notmuchmail.org>
Subject: questions about post-new/insert hooks
User-Agent: Notmuch/0.19+9~gdca38d0 (http://notmuchmail.org) Emacs/24.4.1
	(x86_64-pc-linux-gnu)
Date: Tue, 23 Dec 2014 13:48:02 -0800
Message-ID: <87k31im419.fsf@servo.finestructure.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha256; protocol="application/pgp-signature"
Precedence: list

--=-=-=
Content-Type: text/plain

Hi, folks.  I was wondering about possible race conditions in the
post-new hook.  Given that the database does not remain locked during
execution of the post-new hook, isn't there a possibility that more new
messages will be added to the database before the post-new hook has
finished processing?  If so, I can imagine multiple ways that might
break typical logic in post-new hooks.  I wonder if this race condition
could be avoided by e.g. sending the post-new hook the message ids of
all newly-added messages on stdin.  The hook could then use the message
ids to process just the new messages, without worrying that other
messages could have been added in the middle of processing.  Has anyone
thought about this?

I was also wondering about per-message insertion hooks.  The new(ish)
insert command has a post-insert hook which is run on a per-message
insertion basis.  What about adding a hook that would run on each
message being added with new?  This would also be a way to get rid of
the above mentioned race condition, and might allow for simpler message
content filtering for those of us using notmuch-new instead of
notmuch-insert.  Maybe in this the per-message hook could get the full
text of the message on stdin, and the message id as argument.

I haven't fully thought the implications of this stuff through, so I
would love to hear what others think.

The reason I bring all this up is that I'm trying to figure out the best
way to integrate spam classification into my notmuch setup, which for
some reason is currently proving exceedingly difficult.

jamie.

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJUmeMSAAoJEO00zqvie6q8Ax8P/2It5iz5Zo2C4S1Agp06jiZC
HdEJiAy5TQCoslofytzhPj3SgK6Px90qLKyTiJ9Luu7yH551GlSt91T6jxL6r67t
5S2lISOFJFWS43cOPE1C0vi+Qyp+VGpHT3b0rxDYOMTwE3zPM3labfGrz51EFyxK
LQnu2UkV0MF/GZsJHkOheDEKUQp53dd/4ON4udR/9qoW+EP2XaMlnT10aIi0lSBw
ljinFMd00v7jCJrNmTdwk3+hNCRGM6o+mlVKGU8zzNWulvi1TJsFjAPm5e60h8jO
WGkHak4rhleiiO3FKhgbzRoJITPLd9LDavAmJ55RsXXa0wWTqeQwxJdjxa5+vH3o
GWk0aoshFxWof/tGChaUGsTh6sj2rvl+W+SSL6RMVm+eTis4XQ+BdQrjnDVCsXzi
P7vxoOE4/0/bCh6y93GHsIhWQgdTHkiSjOuah5U9fcTzE3aMTLil9fyJR4WkOiJP
1+UOJHKRvgAKt8RTOWArAyZG+HIA+Zq8Ix30eVnf0chtGjPA+275bVbl8N6Nf7yd
bM3PrI73PvJvnpuuvALy0dklgrTQr2humqPIFivKWruWTq2GQb8QJHF3qye5Rt78
4dxckg/lgyDKP7y8xZO86a+lqiseLulh8CC6Zcmvusnl7a5SVVzd2/hlvL01Hncy
w/3PA7EXWXmW/wyAAyX1
=3QK9
-----END PGP SIGNATURE-----
--=-=-=--