[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libvir] Make python binding release GIL when using threads



On Mon, Oct 09, 2006 at 11:40:21AM -0400, Daniel Veillard wrote:
> On Fri, Oct 06, 2006 at 01:10:18AM +0100, Daniel P. Berrange wrote:
> > In the virt-manager app I'm using the python bindings to libvirt for all
> > operations.  For long running operations such as creating new domains, or
> > saving/restoring domains I fork a background thread to do the call, so that
> > the main UI / status refresh can carry on working. Except this wasn't working.
> > The main thread was being blocked for the entire duration of the background
> > thread.  After a lot of nasty debug sessions I discovered that the main 
> > thread was being blocked in the GTK event loop attempting to aquire the
> > Python GIL (Global Interpreter Lock). The only way this could be occurring
> > is if the background thread doing the libvirt call held the GIL.
> > 
> > And indeed after looking at the source for the libvirt python bindings it
> > appears we never release the GIL when calling into the libvirt C apis, so
> > for the entire duration of virDomainCreateLinux  the python interpreter
> > is completely stopped. Clearly this sucks because virDomainCreateLinux
> > can take a very long time.
> 
>   Okay, true. Simply that I never had to deal with something similar in
> the past so I never looked into this before.

I've been doing more testing with this patch & virt-manager and it all seems
to be operating as desired, so I've committed this patch to CVS.

> > >     output.write("libvirt_begin_allow_threads;\n");
> > 425a427
> > >     output.write("libvirt_end_allow_threads;\n");
> 
>   I was wondering if it wasn't nicer to use functions rather than inlined 
> macros. Maybe if kept as macro this should be turned to upper case to 
> keep consistant with existing practice, but it's not a big deal.

I changed the macros into uppercase to match coding standards. They can't
actually be written as functions because the BEGIN macro opens a statement
block with '{' and declares a local variable within it, that the END macro
then uses & closes.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]