From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1K7XQx-0002Q2-UL
	for qemu-devel@nongnu.org; Sat, 14 Jun 2008 11:12:51 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1K7XQv-0002P6-Rx
	for qemu-devel@nongnu.org; Sat, 14 Jun 2008 11:12:51 -0400
Received: from [199.232.76.173] (port=48808 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1K7XQv-0002Ow-MJ
	for qemu-devel@nongnu.org; Sat, 14 Jun 2008 11:12:49 -0400
Received: from ag-out-0708.google.com ([72.14.246.243]:50395)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1K7XQu-0003gG-R1
	for qemu-devel@nongnu.org; Sat, 14 Jun 2008 11:12:49 -0400
Received: by ag-out-0708.google.com with SMTP id 31so8273490agc.5
	for <qemu-devel@nongnu.org>; Sat, 14 Jun 2008 08:12:47 -0700 (PDT)
Message-ID: <4853DFDF.7000501@codemonkey.ws>
Date: Sat, 14 Jun 2008 10:12:31 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH] Merge NBD client/server int qemu-nbd
References: <1213370134.4833.29.camel@frecb07144>	<4852B339.5090307@codemonkey.ws>
	<1213382394.3803.9.camel@frecb07144>
In-Reply-To: <1213382394.3803.9.camel@frecb07144>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

Laurent Vivier wrote:
> Le vendredi 13 juin 2008 à 12:49 -0500, Anthony Liguori a écrit :
>   
>> Laurent Vivier wrote:
>>     
> [...]
>   
>>> +static void show_parts(const char *device)
>>> +{
>>> +    if (fork() == 0) {
>>> +        int nbd;
>>> +
>>> +	/* wait device */
>>> +        sleep(1);
>>>   
>>>       
>> This looks like a big red-herring.  What is this sleep waiting for any 
>> can it be possibly made into something less racy?
>>     
>
> Yes, I know, it's BAD (and it can failed sometime...)
>
> But show_parts() must wait its parent has entered in nbd_trip() loop.
>   

You mean, listen() has to be called on the fd in the server?  You have 
two choices I think.  You could wait to fork the child until after 
you've listen()'d which is probably the most elegant solution.  If 
that's difficult to do, you could have the child inherit one end of a 
pipe() and use that in the child to wait for the server to be ready.

Regards,

Anthony Liguori

> Because the open() calls /dev/nbd0 which calls through the socket its
> parent and IMHO there is no easy way to know if the server is ready to
> process the request.
>
> Perhaps something like:
>
> int timeout = 5;
> while ((fd = open(device, O_RDWR)) == -1 && timeout--)
>     sleep(1);
>
> Any suggestion ???
>
> Regards,
> Laurent
>