On Tue, Feb 06, 2007 at 02:36:07AM +0000, Brian Brunswick <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]