[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 6/7] libxl: fork: Provide ..._always_selective_reap
Ian Jackson wrote: > Jim Fehlig writes ("Re: [PATCH 6/7] libxl: fork: Provide > ..._always_selective_reap"): > >> Ian Jackson wrote: >> >>> + /* libxl owns SIGCHLD all the time, but it must only reap its own >>> + * children. The application will reap its own children >>> + * synchronously with waitpid, without the assistance of SIGCHLD. */ >>> + libxl_sigchld_owner_libxl_always_selective_reap, >>> >> Should there be some documentation in the opening comments of >> "Subprocess handling"? E.g. an entry under "For programs which run >> their own children alongside libxl's:"? >> > > Yes. > > >> BTW, it is not clear to me how to use libxl_childproc_setmode() wrt >> different libxl_ctx. Currently in the libvirt libxl driver there's a >> driver-wide ctx for more host-centric operations like >> libxl_get_version_info(), libxl_get_free_memory(), etc., and a >> per-domain ctx for domain-specific operations. The current doc for >> libxl_childproc_setmode() says: >> > > Oh dear. Can you change it to use the same ctx everywhere ? > What would be the downside of this in a multi-threaded application, where there are many concurrent domain operations? I was under the impression that such an app would need a per-domain ctx. Regards, Jim > If not, I'm afraid, someone needs to > - keep a record of all the libxl ctxs > - when the self-pipe triggers, iterate over all the ctxs calling > libxl_childproc_sigchld_occurred > > If that "someone" is libvirt, you'll have to do the self-pipe trick. > > It would probably be easier to have libxl maintain a global list of > libxl ctx's for this purpose. > > >> When calling setmode() on the driver-wide or on each domain-specific >> ctx, I get an assert with this hunk >> >> libvirtd: libxl_fork.c:241: libxl__sigchld_installhandler: Assertion >> `!sigchld_owner' failed. >> > > The problem is that the SIGCHLD ownership is attached to the > individual ctx. This could in principle be changed, I think. > > I will try to see if I can do that. > > Ian. > > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |