Re: [Xen-devel] [PATCH] fix assert fail in libxl__sigchld_installhandler

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2013-11-25 at 16:42 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH] fix assert fail in 
> libxl__sigchld_installhandler"):
> > On Mon, 2013-11-25 at 11:56 +0000, Ian Jackson wrote:
> ...
> > > If you are running multiple different long-running libxl operations in
> > > parallel, then either:
> > >  (a) they must all use the same libxl ctx
> > > or
> > >  (b) you must specify libxl_sigchld_owner_mainloop and demultiplex
> > >      SIGCHLD yourself
> > 
> > I was going to ask if it were valid to use
> > libxl_sigchld_owner_libxl_always for one ctx and
> > libxl_sigchld_owner_mainloop for all the others (in essence delegating
> > the requirements of _mainloop to the one special ctx). The answer is no,
> > due to the requirement for users of _mainloop to call
> > libxl_childproc_exited, which _libxl_always does not do for you,
> > certainly not for other ctxts.
> 
> I guess you _could_ do that, actually.
> 
> What you would do is provide a reaped_callback to the _libxl_always
> ctx.  And in that callback, you would iterate over all your other ctxs
> calling libxl_childproc_reaped.
> 
> The locking would be tricky.
> 
> Hmm.  I guess you could have a special libxl ctx whose only purpose
> was to deal with the sigchld.  Then its lock would be outside the lock
> protecting your list of contexts, and outside all of your libxl locks,
> and the reaped_callback could just do the obvious thing.  You would
> have to call libxl_event_wait on that ctx on some thread.
> 
> Is it best not to mention these possibilities ?

I think so!

> 
> Ian.



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