> Can you reproduce this with any other components besides wombat? Hm. Interesting.
bonobo-application-x-mines behavior: 1. First copy is launched by oafd, calls oaf_active_server_register, which outputs the IOR and returns OAF_REG_SUCCESS 2. Second through fourth copies are launched by oafd, each calls oaf_active_server_register, which outputs the IOR of the already-registered first bonobo-application-x-mines and returns OAF_REG_ALREADY_ACTIVE. bonobo-application-x-mines fails to notice the error return and continues running. Result: four successful oaf-client calls all returning the same answer. One working and three dead bonobo-application-x-mines processes. wombat behavior: 1. First copy is launched by oafd, calls oaf_active_server_register several times. Each call returns OAF_REG_SUCCESS and one of them prints out an IOR because it's registering the --oaf-activate-iid server. 2. Second through fourth copies are launched by oafd. Each makes the first of its several oaf_active_server_register calls, but the first one isn't the interface it was launched to provide, so it doesn't output an IOR. wombat notices the OAF_REG_ALREADY_ACTIVE return value, so it prints a message that wombat is already running and then exits without ever trying to register the other interfaces. Result: one successful oaf-client call and three failures. One working wombat. > > The problem is that each call to impl_OAF_ObjectDirectory_activate after > > the first is called from inside the g_main_run in the > > oaf_internal_server_by_forking_extended that gets called by the previous > > impl_OAF_ObjectDirectory_activate. > > Can you give me some more detail on this? > > What is it about this re-entrancy that makes it break? impl_OAF_ObjectDirectory_activate is called, looks in its hash table, sees that the wombat is not running, and starts to activate it. While it's waiting for wombat to activate, impl_OAF_ObjectDirectory_activate is called again, looks in its hash table, sees that wombat is not running, and starts to activate it. While it's waiting for that second wombat to activate, ... > > I looked at trying to fix this, but it's going to require some not-tiny > > code reorganization, I think. (If it turns out to be too annoying to fix > > quickly for oaf 0.x, a simple hacky solution would be to return a > > "TryAgain" exception and have liboaf loop until it doesn't get that...) > > That sounds like a passable workaround. Well, I'll leave you to do that if you want, since it looks now like we can "fix" evolution without even needing an oaf release by just making wombat always try to register every interface before exiting. -- Dan _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers