[imapfilter-devel] IMAP IDLE vs become_daemon
Paul
imapfilter at airbred.com
Fri Apr 23 09:43:13 EEST 2010
Hello,
I'd like to hear how people have approached the main loop for imapfilter
(if they have). Currently I do in-and-out jobs with imapfilter, and
trigger them via cron. However, I want to get more complex and
daemonise what I am doing and have it run forever.
So become_daemon can effectively replace cron, by calling a function
periodically. My first question is, if I set the polling to be, for
example, 45 seconds, and the function I call for some reason takes
several minutes to run, what happens? Would I end up with several
processes running concurrently trying to achieve the same thing?
My second question is about imap idle.
Lets say I have, psuedo code:
repeat
recent, exists, unseen = account:INBOX:get_status()
process_my_inbox()
update = enter_idle(account.INBOX)
until 1=0
So I want to continually monitor my inbox and process whenever something
happens. What would be the best way to daemonise this? Or would it be
best not to? I have a series of mailboxes I want to monitor so would I
have a series of functions that monitor each mailbox, and then daemonise
each one with an arbitrarily big interval?
Lastly, and this is more of a logic question, if the process_my_inbox
gathers a whole bunch of mail from INBOX (say select_all()), and then
does various things to it, which takes time, and I return from that
function to enter_idle once more, presumably if anything has changed in
the mailbox in between my function doing the select_all and exiting the
function, this won't be seen by enter_idle - it would have happened
before idle was called. So should the "process_my_inbox" function be
wrapped in its own loop where I check for status changes at the end of
the processing to see whether it needs to go back in, or whether it is
appropriate to enter_idle because nothing has changed?
Thanks for any help. I have read David DeSimone's explanation of his
approach, and he seems to do some of the things I am talking about here.
Paul
More information about the Imapfilter-devel
mailing list