Re: [Xen-devel] [PATCH 05/19] libxl: events: Use libxl__xswait_* in spawn code

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2014-03-10 at 10:26 +0000, Ian Jackson wrote:
> Lai Jiangshan writes ("Re: [PATCH 05/19] libxl: events: Use libxl__xswait_* 
> in spawn code"):
> > On 03/04/2014 10:56 PM, Ian Jackson wrote:
> > > Replace open-coded use of ev_time and ev_xswatch with xswait.
> ...
> > > +    ss->xswait.ao = ao;
> > > +    ss->xswait.what = GCSPRINTF("%s startup", ss->what);
> > > +    ss->xswait.path = ss->xspath;
> > > +    ss->xswait.timeout_ms = ss->timeout_ms;
> > > +    ss->xswait.callback = spawn_watch_event;
> > > +    rc = libxl__xswait_start(gc, &ss->xswait);
> > 
> > This is another kind of open code, I guess it should be wrapped into
> > a function.
> 
> I'm not sure I follow.  These are, effectively, the arguments to
> libxl__xswait_start.  libxl__xswait_start takes its "arguments" inside
> the xswait structure.   So the LHS are formulaic but the RHS are all
> specific to the call site.
> 
> I guess we could use GCC's compound literal syntax, with something
> like this:
> 
>    ss->xswait = (libxl__xswait_state){
>       .ao = ao,
>       .what = GCSPRINTF("%s startup", ss->what),
>       .path = ss->xspath,
>       .timeout_ms = ss->timeout_ms,
>       .callback = spawn_watch_event,
>    };
> 
> But that's not an improvement IMO.

Nor mine.

Ian.


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