Re: [PATCH 3/3] rpc: Rework rpc notifications in main and side thread

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

 



On Fri, Dec 15, 2023 at 03:51:19PM +0100, Denis V. Lunev wrote:
> On 12/15/23 14:48, Efim Shevrin wrote:
> > *From:* Daniel P. Berrangé <berrange@xxxxxxxxxx>
> > *Sent:* Friday, December 15, 2023 19:09
> > *To:* Efim Shevrin <efim.shevrin@xxxxxxxxxxxxx>
> > *Cc:* devel@xxxxxxxxxxxxxxxxx <devel@xxxxxxxxxxxxxxxxx>; den@xxxxxxxxxx
> > <den@xxxxxxxxxx>
> > *Subject:* Re: [PATCH 3/3] rpc: Rework rpc notifications in main and
> > side thread
> > [You don't often get email from berrange@xxxxxxxxxx. Learn why this is
> > important at https://aka.ms/LearnAboutSenderIdentification ]
> > 
> > On Fri, Dec 15, 2023 at 02:32:19AM +0800, Fima Shevrin wrote:
> > > RPC client implementation uses the following paradigm. The critical
> > > section is organized via virObjectLock(client)/virObjectUnlock(client)
> > > braces. Though this is potentially problematic as
> > >     main thread:                            side thread:
> > >     virObjectUnlock(client);
> > > virObjectLock(client);
> > > g_main_loop_quit(client->eventLoop);
> > > virObjectUnlock(client);
> > >     g_main_loop_run(client->eventLoop);
> > >
> > > This means in particular that is the main thread is executing very long
> > > request like VM migration, the wakeup from the side thread could be
> > > stuck until the main request will be fully completed.
> > 
> > Can you explain this in more detail, with call traces illustration
> > for the two threads. You're not saying where the main thread is
> > doing work with the 'client' lock hold for a long time. Generally
> > the goal should be for the main thread to only hold the lock for
> > a short time.  Also if the side thread is already holding a reference
> > on 'client', then potentially we should consider if it is possible
> > to terminate the event loop without acquiring the mutex, as GMainLoop
> > protects itself wrt concurrent usage already, provided all threads
> > hold a reference directly or indirectly.
> 
> At our opinion the problem here is missed wakeup from
> the side thread to the main thread.

Hmmm, what platform are you seeing problems on ? Are you still targetting
a very old RHEL-7 platform ?  I vaguely recall there are/weere some old
glib bugs in the main loop with threads that could be applicable.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
_______________________________________________
Devel mailing list -- devel@xxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux