Re: Another oaf race condition

[Dan Winship <danw ximian com>]

> 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