From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NuPmo-0008SO-Sp for qemu-devel@nongnu.org; Wed, 24 Mar 2010 08:34:15 -0400 Received: from [140.186.70.92] (port=37995 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NuPme-0008P5-IU for qemu-devel@nongnu.org; Wed, 24 Mar 2010 08:34:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NuPmX-00062b-4h for qemu-devel@nongnu.org; Wed, 24 Mar 2010 08:34:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:2006) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NuPmW-00061n-Sd for qemu-devel@nongnu.org; Wed, 24 Mar 2010 08:33:57 -0400 Message-ID: <4BAA06AA.6090907@redhat.com> Date: Wed, 24 Mar 2010 14:33:46 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt References: <4BA7C40C.2040505@codemonkey.ws> <20100323145105.GV16253@redhat.com> <4BA8D8A9.7090308@codemonkey.ws> <201003231557.19474.paul@codesourcery.com> <4BA8E6FC.9080207@codemonkey.ws> <4BA901B5.3020704@redhat.com> <4BA9A066.3070904@redhat.com> <20100324103643.GB624@redhat.com> <4BA9EC88.6000906@redhat.com> <4BAA0425.2030206@codemonkey.ws> <4BAA05BD.1040708@redhat.com> <4BAA064F.6010306@codemonkey.ws> In-Reply-To: <4BAA064F.6010306@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: "libvir-list@redhat.com" , Paul Brook , qemu-devel@nongnu.org On 03/24/2010 02:32 PM, Anthony Liguori wrote: >> You don't get a directory filled with a zillion socket files pointing >> at dead guests. Agree that's a poor return on investment. > > > Deleting it on atexit combined with flushing the whole directory at > startup is a pretty reasonable solution to this (which is ultimately > how the entirety of /var/run behaves). > > If you're really paranoid, you can fork() a helper with a shared pipe > to implement unlink on close. My paranoia comes nowhere near to my dislike of forked helpers. -- error compiling committee.c: too many arguments to function