Bug#409872: On slow arch apt just wastes cpu while waiting for dpkg to run

[Daniel Burrows <dburrows@debian.org>]

On Tue, Feb 06, 2007 at 02:36:07AM +0000, Brian Brunswick <bdb-reportbug@forbidden.co.uk> was heard to say:
> I'm running apt from an nfs-mounted chroot of the real disk inside a 
> qemu-system-arm instance. This is quite slow, but better than the real machine
> (nslu2) which has infeasibly little memory (32MB) [When I was young...],
> at least for modern big package databases.
> 
> However, I notice that while dpkg is running to decompress something,
> apt is still taking about as much cpu as the dpkg instance. This is sad,
> giving that all its doing is waiting.

  I bet the culprit is the read on line 590 of dpkgpm.cc:

	 // read a single char, make sure that the read can't block 
	 // (otherwise we may leave zombies)
         int len = read(_dpkgin, buf, 1);

  It's followed by a usleep() call and a jump to the top of the loop
if no data is available.  "are we there yet? are we there yet?
are we there yet?" ad infinitum...

  I don't believe the comment claiming that we'd get zombies if the read
blocked.

  You get zombies if you don't waitpid() on them when they die, which this
loop is quite conscientuous about doing.  Perhaps the code is worried about
blocking indefinitely in read() if dpkg dies?  But if dpkg dies, the pipe
will be closed and read should terminate with an error (the code properly
closes the unused pipe endpoints, so it won't hang around).  There may be a
concern due to the fact that SIGINT is blocked, but again it should be
passed to the subprocess, which would kick us out of this loop.

  I don't see the reason for not blocking in this read, but I could just
be stupid this morning.  Does anyone else have a suggestion?

  Daniel