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

Re: [Xen-devel] [PATCH 23/24] libxl: child processes cleanups



On Tue, 2012-04-24 at 16:05 +0100, Ian Campbell wrote:
> On Tue, 2012-04-24 at 15:27 +0100, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [PATCH 23/24] libxl: child processes 
> > cleanups"):
> > > On Mon, 2012-04-16 at 18:18 +0100, Ian Jackson wrote:
> > > > Abolish libxl_fork.  Its only callers were in xl.  Its functionality
> > > > is now moved elsewhere, as follows:
> > ...
> > > >  static inline int libxl__ev_child_inuse(libxl__ev_child *childw_out)
> > > >                  { return childw_out->pid >= 0; }
> > > >  
> > > > +/* Useable (only) in the child to once more make the ctx useable for
> > > > + * xenstore operations.
> > > 
> > > Specifically "the child" is the middle child of a spawn? Otherwise the
> > > constraint must be something like "before any threads are created in the
> > > new process", or something like that?
> > 
> > The fact that raw fork() may be used in the child created by
> > libxl__ev_child_inuse isn't documented.  It would be possible to
> > document this but the set of restrictions on the behaviours of the
> > middle child and any resulting grandchildren are rather complex.
> > 
> > I think it might be better to draw a veil over this and leave it as a
> > special piece of knowledge implicit in the implementation of
> > libxl__spawn_*.
> 
> OK.

Looking back at my review, my only other comment was just a suggestion
which you can implenment if you want, which means that OK ->

Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>

> 
> > In practice the use of _xenstore_reopen in the middle child is fine
> > provided that the middle child doesn't then fork _and_ then use
> > libxl's xenstore functions in both the middle child and the
> > grandchild.
> > 
> > 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®.