Re: Bits from the Testing Security team
Kurt Roeckx writes ("Re: Bits from the Testing Security team"):
> Decompression is typicly something that is i/o bound, not cpu bound.
If the package is stored on disk and not in buffer cache. However, in
many cases the package will have been just downloaded and so on a big
memory machine like a modern workstation may well be entirely in
buffer cache.
> What I think running it in a separate process does it creating 2 pipes
> you don't need. You can just do everything in the local memory of 1
> process.
Are you confusing "I/O bound" with "makes read/write syscalls" ? I/O
bound means that the limiting factor is mass storage performance. If
the data is in main memory then mass storage performance is
irrelevant.
The overhead (cpu cost) of reading or writing the contents of the .deb
a few times through some pipes is irrelevant compared to both the cpu
cost of decompressing it and of course the cpu cost of processing each
file during installation.
> On Tue, Oct 16, 2007 at 02:34:36PM +0100, Ian Jackson wrote:
> > Having dpkg invoke the decompresser as a separate program provides
> > several IMO important advantages. It simplifies the code in dpkg, and
> > it greatly simplifies the management of cross-version compatibility
> > and multiple optional decompression schemes (including experimental
> > ones), by decoupling dpkg from the decompressers.
>
> I see no reason why we can't have both available.
!
dpkg has to be compiled one way in the distribution.
And if there is no good reason to have the decompressors bound in then
having that facility wired into the code is just extra complexity to
no useful purpose.
Ian.
Reply to: