pan-users
[Top][All Lists]
Advanced

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

Re: [Pan-users] Re: If SQLite has NFS locking problems... (was Re: Big X


From: Ron Johnson
Subject: Re: [Pan-users] Re: If SQLite has NFS locking problems... (was Re: Big XML files... (was ...))
Date: Sat, 04 Jul 2009 20:24:18 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.19) Gecko/20090103 Thunderbird/2.0.0.19 Mnenhy/0.7.6.666

On 2009-07-04 18:40, Duncan wrote:
Ron Johnson <address@hidden> posted
address@hidden, excerpted below, on  Sat, 04 Jul 2009 15:13:10
-0500:

Is Pan multi-threaded, so that the data store (currently, flat files) is
concurrently accessed?

pan is "selectively multithreaded", that is, generally single threaded for simplicity of code without races (old-pan was multithreaded and Charles didn't like the debugging or difficulty of no-race coding, I guess), but it spawns worker threads at the worst bottlenecks. One of those was when first setting up the network connections. I'm not sure about the others. (I'm not really a coder myself, but pay attention to what I read, and know enough about it to follow a decent bit of it.)

a) breaking tasks.nzb into multiple files under tasks/, and having
    a b-tree index to make it quick to rearrange queued tasks, and to
    delete tasks once they are completed or deleted.

tasks.nzb was new with new-pan, and is a cross-application standard, as are the newsrc files. I'm not sure what the tradeoffs were or whether that's enough of the bottleneck to be worth breaking the standard to attempt to fix.


So it lets me move from one reader to another without losing my download queue? That would be handled thru File->Export->Tasks.

There's usually a better way to optimally represent data than with unstructured text.

--
Scooty Puff, Sr
The Doom-Bringer




reply via email to

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