Re: [Pan-users] Re: Forcing an expire?

[Ron Johnson]

On 2009-07-11 01:44, K. Haley wrote:
> Duncan wrote:
> > Ron Johnson <address@hidden> posted
> >
> >   
> > > The problem now is that the nntp pipes are so fat that, "because" of
> > > multi-threading, the tasks.nzb.tmp flush starts again only 3-5 seconds
> > > after the previous flush completed.
> > >     
> This was a bug ( sort of ).  Pan has a built in 10sec delay between
> updates of tasks.nzb but it was counting from the start of the update
> not the end.  It's now fixed.
> > > This is why I was pushing for on-disk structures instead of having to
> > > flush memory structures to disk.
> > >
> > > If SQLite is bad, then maybe Berkeley DB.  It's got rollbacks, fine
> > > grained locking.  KLibido, a KDE newsreader, uses it for a similar
> > > purpose.
> > >     
> > > *Something* so that a 10KB change in tasks does not require a 300MB file
> > > to be written to disk.
> > >     
> > I still believe that's barking up the wrong tree, at least for tasks.nzb 
> > (the 3+ gig header file for a single group is a different matter 
> > entirely).
> >   
> Definitely barking up the wrong tree for tasks.  A simpler solution that
> doesn't require any new dependencies would be one file per task. 
> Obviously not a solution for most users that don't have such large tasks
> files, but it might be possible to make it a run time option.

Or a separate "flush tasks.nzb" thread, which would not block any 
other process.

> > Now, something that actually DOES make sense, would be what pan already 
> > does for the newsgroup state, don't write it back to disk for every 
> > single change!  Pan delays the read message tracking (newsrc) writes, and 
> > possibly the header file writes (I'm not sure) until group change.
> >
> > Now with tasks.nzb we probably don't want to wait that long, but pan 
> > could EASILY build up changes in memory and actually write out tasks.nzb 
> > every minute or so.  
> >
> > Actually, one would hope that'd be a reasonably small patch, likely able 
> > to go into K. Haley's git repo version.  If anyone with the coding skills 
> > is so motivated, of course...
> >   
> Changing the delay is a one liner.  Although now that I think about it I
> could make it a config file option.

That would be a serious win!  And *very* much appreciated.

--
Scooty Puff, Sr
The Doom-Bringer