9front - general discussion about 9front
 help / color / mirror / Atom feed
From: ori@eigenstate.org
To: ori@eigenstate.org, cinap_lenrek@felloff.net, 9front@9front.org
Subject: Re: [9front] [patch] upas: plumb flag updates on messages.
Date: Mon Dec  9 10:29:53 PST 2019	[thread overview]
Message-ID: <01756337F576722545F2D4F171E99774@eigenstate.org> (raw)

>> ok, small remarks.
>> 
>> +			if(doplumb){
>> +				if((m->cstate & Cnew) && ensurecache(mb, m) == 0)
>>  					msgdecref(mb, m);
>> 
>> i think you want to do the msgdecref() of the message *after* mailplumb(),
>> not before. otherwise its like free before use. i know with the current
>> code it will still work but it is semantially wrong. if we later change
>> how cache eviction works that will blow up.
> 
> Ok. I was looking at the code, and it *seemed* like the intent was
> to have even evicted messages be somewhat valid. I think there are a
> number of places where we manipulate seen but not cached messages.
> 
>> +		print("child\n");
>> +		if(mboxfile != nil)
>> +			if(err = newmbox(mboxfile, "mbox", 0, nil))
>> +				sysfatal("opening %s: %s", mboxfile, err);
> 
>> theres a debug print left there and this changes some semantics.
>> i know this is because initial sync from imap takes forever. but
>> people sometimes want to specify mailbox path at the initial
>> command line and expect error status if the initial sync failed
>> (like if mounting a mbox file in a script to parse a message).
> 
> Right, forgot about this change. Reverted -- It doesn't even
> make things respon faster, since the mount doesn't return until
> after we do the initial sync.
> 
>> i think a good compromise would be to add a commandline flag to
>> specify if you want initial sync in the background or not
>> (can then be added to /rc/bin/startupasfs).
>>
>> if we do background syncing, then even if the initial sync
>> fails, it should try to continue. imagine your imap server
>> is currently down or network is unavailable, you want it to
>> continue trying in that case. and sysfataling here makes no
>> sense as nobody will be listening.
> 
> Yes. background sync will need a bunch more work, and a lot
> more thought to get right.
> 
> Updated patch below, slipped in 2 small changes:
> 
>  - Acme Mail => Next button to take you to the next msg
>  - Imap => small consistency tweak: flags are uint.
> 
> Can back them out if you care about separating them.
> 


+			if((m->cstate & Cnew|Cmod) && ensurecache(mb, m) == 0){

And I attached the wrong version of the patch. The one I tested
has (m->cstate & (Cnew|Cmod))



             reply	other threads:[~2019-12-09 18:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-09 18:29 ori [this message]
  -- strict thread matches above, loose matches on Subject: below --
2019-12-09 20:28 cinap_lenrek
2019-12-09 12:00 cinap_lenrek
2019-12-09 18:07 ` ori
2019-12-09 18:29   ` ori

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=01756337F576722545F2D4F171E99774@eigenstate.org \
    --to=ori@eigenstate.org \
    --cc=9front@9front.org \
    --cc=cinap_lenrek@felloff.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;
as well as URLs for NNTP newsgroup(s).