[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

Ian.

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.