On 1/9/20 12:12 PM, George Dunlap wrote: > libxl needs to be able to know when processes it forks have completed. > > At the moment, libxl has two basic mode (with some variations). In > one mode -- libxl_sigchld_owner_libxl* -- libxl sets up its own > SIGCHLD signal handler, and also handles the event loop that allows > libxl to safely block until the child in question is finished (using a > self-pipe for the SIGCHLD handler to notify the waiters that it's time > to look for reaped children). > > In the other mode, libxl does not set up the SIGCHLD handler, nor does > it do anything with processing the event loop; it expects the library > caller to handle the event loop itself. > > The golang runtime manages its own processes, and thus must use > SIGCHLD itself; and it has an easy way for other users to get SIGCHLD > notifications. However, because its event loop is hidden away behind > abstractions, it's not easy to hook into; and there's no need -- the > golang runtime assumes that C function calls may block, and handles > everything behind the scenes. > > Introduce a new mode, libxl_sigchld_owner_notify, in which libxl sets > up the SIGCHLD event handling machinery, but relies on the caller to > tell it when a SIGCHLD happens. > > Call these two actions "notify" (for the self-pipe notification > machinery) and "handler" (for the actual SIGCHLD handler). > > Provide a new external function, libxl_childproc_sigchld_notify(), for > library users to call when a SIGCHLD happens. Have this call > sigchld_handler(). > > Rename chldmode_ours() to chldmode_notify(), and use it to determine > whether to set up the notification chain. > > When setting up the notification chain, do everything except setting > up the signal handler in "notify-only" mode. > > defer_sigchld() and release_sigchld() do two things: they modify the > signal handler, and grab and release locks. Refactor these so that > they grab and release the locks correctly in "notify-only" mode, but > don't tweak the signal handler unless it's been set up. > > With the golang bindings ported to use this change, domain creation > works. > > NB an alternate approach would be to make libxl_sigchld_owner_mainloop > *always* set up and tear down the self-pipe notification mechanisms, > and then simply expose libxl_childproc_sigchld_notify(). However, > this would entail grabbing a libxl-wide global lock (across all libxl > ctx's) twice on every fork. This should be avoided for callers which > don't need it. > > Signed-off-by: George Dunlap <george.dun...@citrix.com>
FAOD, with the fixes in your other series, I consider this patch to now be moot. - George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
