Re: [Xen-devel] [OSSTEST PATCH 08/13] Planner: ms-queuedaemon: Prep for multiple walkers

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Wed, 2015-09-02 at 16:45 +0100, Ian Jackson wrote:
> We are going to introduce multiple concurrent streams of planning
> processing, called `walkers'.
> 
> Prepare the ground for this with some formulaic changes which will
> otherwise greatly clutter substantive patches.
> 
> (A client will still only think for one walker at once, because that's
> what the client protocol expects - and anything else would be far too
> confusing.)
> 
> General:
>  * Introduce the concept of a `walker' to ms-queuedaemon.
>  * Provide a list of the walkers which might exist, `walkers'
>  * Provide some helper procedures for iterating over these,
>    and easily accessing their state.
> 
> Queue handling:
>  * Add a new `w' argument to many procs: specifically, most of the
>    procs in the section `machinery for running the queue'.
>  * Log the walker ($w) at the start of all relevant log messages.
>  * Pass the -w option to ms-planner and ms-planner-debug.
>  * Add safety catches which will crash the ms-queuedaemon if it finds
>    it is asking the same client to think for more than one walker.
>  * we-are-thinking and check-we-are-thinking tell the caller what
>    walker the client is thinking for.
>  * In the resource-plan.html filename, replace `plan' with the walker
>    filename.
> 
> Elsewhere:
>  * Teach dequeue-chan to deal with all the walkers, including
>    maybe the (one) walker for which the client is thinking.
>  * Teach log-state to report on all the walkers.
>  * In the runneeded logic, hardcode `plan' as the walker to use.
> 
> There is still actually only one walker.
> 
> No overall functional change, except to some log messages.
> 
> Signed-off-by: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>

This mostly seems plausible, in so far as I can speak tcl.

You spotted a bug while explaining the intricacies of upvar/uplevel to me
IRL, but I didn't see anything further...


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel