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

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



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 ?

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®.