Re: [PATCH][RFC] making "xm dump-core" paralell

[Rikiya Ayukawa <ayukawa.rikiya@np.css.fujitsu.com>]

Hi,

# Sorry, I mistook the function name on e-mail.
# xc_domain_dump() -> xc_domain_dumpcore()

> - Add xc_dumpcore program. This program only calls xc_domain_dump()
> >   in libxc to dump the core image of a domainU.
>   
>
> Why?

To make xend call indirectly xc_domain_dumpcore() written by C.
I think this is similar to xc_save and xc_restore programs.

xend (cset#15880:a00cc97b392a) calls xc_domain_dumpcore() directly.
It takes xend a lot of time to finish this C function.

Until the xend's thread finishes xc_domain_dumpcore(), any other xend's
thread
don't run because of GIL (global interpreter lock) in CPython specification.

http://docs.python.org/api/threads.html

# If xc_domain_dumpcore() release GIL sometimes, other xend's thread can
run.
# But I guess not.

By changing xend to create a xc_dumpcore process and
to wait for the process to finish, xend don't begin to call C function
directly,
so that other xend's thread can run while dealing with dump-core.

Thank you,

Rikiya Ayukawa