|
[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |