Re: Acquire considered non-threadsafe
On Sun, Nov 15, 2009 at 12:42:38PM -0800, Daniel Burrows wrote:
> There are some other very nice options involving rewriting or
> reimplementing the "download queue" logic (i.e., just pkgAcquire), but
> getting threadsafety does require changing the behavior of
> pkgAcquire::Item in any event. I'm assuming that we don't want to have
> two parallel implementations of this functionality, and that
> non-backwards-compatible changes are considered unacceptable, in which
> case the opt-in approach is the only solution I can think of.
We should really start talking about APT 0.8 sometime soon, and break
some APIs. The problem I have with Acquire is its low speed when queuing
items which is probably caused by the use of a linked list (20000 items
take multiple minutes to be queued, whereas APT2 queues them in less than
a second[1]).
Other ideas:
(a) a common abstract base class for the *Summation classes
(b) a new cache format which can be resized in reality
(c) new dependency resolver [porting aptitude's one?]
(d) external dependency resolvers
(e) new buildsystem (e.g. raw autotools) and reworked
packaging
(f) storing errno inside the error handling objects,
for bindings (nice to have errno).
The whole thing could be targeted for Squeeze+1, i.e. for 2012; with
0.8.0 in November 2010; so we have one additional year to stabilize
things again.
But I don't think anyone wants to do this.
[1] APT2 only has a sequential fetcher with one queue (an array-using list)
at the moment, it may be a bit slower once there are multiple workers
and queues. But I don't expect it to be as slow as APT's.
--
Julian Andres Klode - Debian Developer, Ubuntu Member
See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
Reply to: