From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2 16/27] tools/libxl: Infrastructure for
 reading a libxl migration v2 stream
Date: Fri, 10 Jul 2015 13:50:02 +0100
Message-ID: <559FBF7A.6020502@citrix.com>
References: <1436466413-25867-1-git-send-email-andrew.cooper3@citrix.com>
	<1436466413-25867-17-git-send-email-andrew.cooper3@citrix.com>
	<1436523793.23508.224.camel@citrix.com>	<559FA2A5.9090105@citrix.com>
	<1436527557.23508.264.camel@citrix.com>	<559FBA8A.3000600@citrix.com>
	<21919.48834.307687.85181@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <21919.48834.307687.85181@mariner.uk.xensource.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Ross Lagerwall <ross.lagerwall@citrix.com>, Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>, Xen-devel <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

On 10/07/15 13:46, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH v2 16/27] tools/libxl: Infrastructure for reading a libxl migration v2 stream"):
>> On 10/07/15 12:25, Ian Campbell wrote:
>>> Do you mean they would do so legitimately in that case, or in error?
>> It is wrong in all cases to mutually recurse like this.  The data
>> controlling the degree of mutual recursion is read from a pipe.
>>
>> The issue with the TOOLSTACK record is that it a synchronous library
>> call, not an aync one.  This is not a problem pe say, but it means that
>> process_record() must queue something further to do.
>>
>> In a checkpoint it is possible (although very unlikely) to have $N
>> thousand TOOLSTACK records back to back.
>>
>> The guards are in place to prevent introducing a codepath which does end
>> up in mutual recursion.  Such a calltree would function for any
>> reasonable input, but would fall off the stack given a certain sequence
>> of records.
> I just wanted to say that I have read this and it helps my
> understanding but I still worry about the correctness of
> stream_continue and process_record if the queue has more than one
> record.

This might also make more sense with the context from patch 25, which is
where the Remus/COLO buffering is introduced.

~Andrew