On Wed, Oct 30, 2024 at 05:58:15PM +0000, Daniel P. Berrangé wrote: > That's a result from moving the "assert()" into the constructor. > The assert(!current_migration) can be kept in migration_object_init, > the constructor could conditionally set current_migration only if it > is NULL, and the finalizer could conditionally clear current_migration > only if it matches the current object. There's no conceptual dependancy > on having a singleton interface in the patch.
Yes that could work, but that sounds more hackish from my POV, trying to detect "which is the real migration object". We need to assume (1) the 1st migration object being created must be the global migration object, then (2) we still allow concurrent creations of such object, which I personally don't really like, even with a hack already. If this series cannot get accepted, I can try go with that, or I'll implement the refcount in migration.c, whichever I found better at last. To me, both are less clean comparing to singleton. -- Peter Xu
