pan-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: K. Haley
Subject: Re: [Pan-users] Re: Forcing an expire?
Date: Sat, 11 Jul 2009 00:44:19 -0600
User-agent: Thunderbird 2.0.0.21 (Windows/20090302)

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.
> 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.


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]