Re: [PATCH] multifd: Make the main thread yield periodically to the main loop

[Fabiano Rosas <farosas@suse.de>]

Lukas Straub <lukasstraub2@web.de> writes:

> On Fri, 8 Aug 2025 11:37:23 -0400
> Peter Xu <peterx@redhat.com> wrote:
>
>> On Fri, Aug 08, 2025 at 10:55:25AM -0300, Fabiano Rosas wrote:
>> > Please work with Lukas to figure out whether yank can be used here. I
>> > think that's the correct approach. If the main loop is blocked, then
>> > some out-of-band cancellation routine is needed. migrate_cancel() could
>> > be it, but at the moment it's not. Yank is the second best thing.  
>> 
>> I agree.
>> 
>> migrate_cancel() should really be an OOB command..  It should be a superset
>> of yank features, plus anything migration speficic besides yanking the
>> channels, for example, when migration thread is blocked in PRE_SWITCHOVER.
>
> Hmm, I think the migration code should handle this properly even if the
> yank command is used. From the POV of migration, it sees that the
> connection broke with connection reset. That is the same error as if the
> other side crashes/is killed or a NAT/stateful firewall in between
> reboots.
>

That should all work just fine. After yank or after a detectable network
failure. The issue here seems to be that the destination recv is hanging
indefinitely. I don't think we ever played with socket timeout
configurations, or even switching to non-blocking during the sync. This
is actually (AFAIK) the first time we get a hang that's not "just" a
synchronization issue in the migration code.

>> 
>> I'll add this into my todo; maybe I can do something with it this release.
>> I'm happy if anyone would beat me to it.
>> 
>> > 
>> > The need for a timeout is usually indicative of a design issue. In this
>> > case, the choice of a coroutine for the incoming side is the obvious
>> > one. Peter will tell you all about it! =)  
>> 
>> Nah. :)
>>