From: Jim Fehlig <jfehlig@suse.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [PATCH 6/7] libxl: fork: Provide ..._always_selective_reap
Date: Fri, 17 Jan 2014 08:16:12 -0700 [thread overview]
Message-ID: <52D9493C.2060506@suse.com> (raw)
In-Reply-To: <21209.5519.308053.311118@mariner.uk.xensource.com>
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.
>
>
next prev parent reply other threads:[~2014-01-17 15:16 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-16 17:22 [RFC PATCH 0/7] libxl: fork: Selective reaping Ian Jackson
2014-01-16 17:22 ` [PATCH 1/7] libxl: fork: Break out checked_waitpid Ian Jackson
2014-01-17 11:09 ` Ian Campbell
2014-01-16 17:22 ` [PATCH 2/7] libxl: fork: Break out childproc_reaped_ours Ian Jackson
2014-01-17 11:10 ` Ian Campbell
2014-01-16 17:22 ` [PATCH 3/7] libxl: fork: Clarify docs for libxl_sigchld_owner Ian Jackson
2014-01-17 11:12 ` Ian Campbell
2014-01-17 12:41 ` Ian Jackson
2014-01-16 17:22 ` [PATCH 4/7] libxl: fork: assert that chldmode is right Ian Jackson
2014-01-17 11:13 ` Ian Campbell
2014-01-16 17:22 ` [PATCH 5/7] libxl: fork: Provide libxl_childproc_sigchld_occurred Ian Jackson
2014-01-17 11:22 ` Ian Campbell
2014-01-17 11:27 ` Ian Jackson
2014-01-17 11:29 ` Ian Campbell
2014-01-17 16:09 ` Ian Jackson
2014-01-16 17:22 ` [PATCH 6/7] libxl: fork: Provide ..._always_selective_reap Ian Jackson
2014-01-17 6:36 ` Jim Fehlig
2014-01-17 11:35 ` Ian Jackson
2014-01-17 15:16 ` Jim Fehlig [this message]
2014-01-17 16:13 ` Ian Jackson
2014-01-17 12:38 ` Ian Jackson
2014-01-17 15:22 ` Jim Fehlig
2014-01-17 11:27 ` Ian Campbell
2014-01-16 17:22 ` [PATCH 7/7] libxl: fork: Provide LIBXL_HAVE_SIGCHLD_SELECTIVE_REAP Ian Jackson
2014-01-17 11:27 ` Ian Campbell
2014-01-16 19:25 ` [RFC PATCH 0/7] libxl: fork: Selective reaping Ian Jackson
2014-01-17 6:41 ` Jim Fehlig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52D9493C.2060506@suse.com \
--to=jfehlig@suse.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=ian.campbell@citrix.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.