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

[Akio Takebe <takebe_akio@jp.fujitsu.com>]

Hi, John

>On Thu, Sep 27, 2007 at 05:36:23PM +0900, Rikiya Ayukawa wrote:
>
>> # 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
>
>But if you're forking, why can't you do it in Python?
The child process of xend can call xc_domain_dumpcore,
but it is worse than execing the new dump command
because we must be careful about some more cases.

For example if we do not use exec(), at least, the child of xend
must unregister the xenwatch to dump a domU at the domU crashing time
because the child process of xend has the same functions of parent.
I think there are many other case that we must be careful
about multi process of xend.

xm save/restore also fork+exec. I think it's the same reason.
Is that right, Keir?

Best Regards,

Akio Takebe