On Wed, Dec 04, 2024 at 06:01:39PM -0300, Fabiano Rosas wrote: > > Considering it's confusing to mostly everyone, and tons of people asked me > > about this.. maybe I should send a patch to remove yank from migration? > > Take a look at my suggestion in the other thread, it might make yank > make sense for migration after all. But I'm not against the removal, > it's better than the current state IMO.
I missed that. Copying that part over: > I asked because for socket at least yank and cancel do the same: > shutdown(). It might be more trouble than it's worth it, but I wonder if > we could have everything that can be stuck implement a yank routine and > just have cancel call those. So for instance, when this series does > sem_post on a bunch of semaphores explicitly, the cancel command would > instead call whatever yank routine was registered by the code that can > wait on the semaphore. With this there should be no surprises of a > cancel arriving at a weird moment, because we'd require "code that > sleeps" to implement a yank. If so, it means migration_cancel will still do the same as what yank would do (but it could cover more now, like processing sleeping semaphores). Actually, since it'll invoke a yank API it'll be the same from that regard. However as long as there's still something extra migrate_cancel would do after that yank API, then we should still suggest nobody using QMP "yank" on migration instance.. Unless we want to precisely define migrate_cancel exactly the same as the yank API would do. But then it means the two APIs are identical, then we should probably keep the one that people use the most, which is still, the migrate_cancel API.. -- Peter Xu
