From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47083) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RmUAc-00041Z-GL for qemu-devel@nongnu.org; Sun, 15 Jan 2012 12:47:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RmUAZ-0008UY-Mc for qemu-devel@nongnu.org; Sun, 15 Jan 2012 12:47:06 -0500 Received: from lo.gmane.org ([80.91.229.12]:37502) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RmUAZ-0008UA-HV for qemu-devel@nongnu.org; Sun, 15 Jan 2012 12:47:03 -0500 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RmUAX-0001q5-VY for qemu-devel@nongnu.org; Sun, 15 Jan 2012 18:47:01 +0100 Received: from 93-34-200-238.ip51.fastwebnet.it ([93.34.200.238]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 15 Jan 2012 18:47:01 +0100 Received: from pbonzini by 93-34-200-238.ip51.fastwebnet.it with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 15 Jan 2012 18:47:01 +0100 From: Paolo Bonzini Date: Sun, 15 Jan 2012 18:46:48 +0100 Message-ID: References: <20120114124210.E43483DE@gandalf.tls.msk.ru> <4F12CB7C.308@msgid.tls.msk.ru> <4F12FAA7.5000103@redhat.com> <4F130261.4010205@msgid.tls.msk.ru> <4F130D78.1070903@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In-Reply-To: <4F130D78.1070903@redhat.com> Subject: Re: [Qemu-devel] [PATCH] rework daemonizing logic in qemu-nbd List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On 01/15/2012 06:31 PM, Paolo Bonzini wrote: > > >> We're doomed anyway, and it is even good >> we've a small remote chance for our error message to >> be seen. Currently it just goes to /dev/null. > > No, currently it is sent from the daemon to the parent through the pipe, > the parent prints it and exits with status code 1. With your patch, if > the dup2 wins the race you exit with status code 0; if the client thread > wins the race it is the same as master. Actually, the dup2 will always win the race. Until the main loop starts and accepts the connection from the client thread, the client thread will be stuck connect()ing to the server socket. So, the client thread will never be able to report problems connecting /dev/nbd (for example you won't get an error if you chose a device that is already busy). So it looks like there is no race, but there is a bug. :) Please disprove me if I'm wrong, of course. Paolo