Another oaf race condition

[Dan Winship <danw ximian com>]

For a bad time:

oaf-client -s "iid == 'OAFIID:Bonobo_Moniker_wombat'" & \
oaf-client -s "iid == 'OAFIID:Bonobo_Moniker_wombat'" & \
oaf-client -s "iid == 'OAFIID:Bonobo_Moniker_wombat'" & \
oaf-client -s "iid == 'OAFIID:Bonobo_Moniker_wombat'" &

You'll get one success and three "unknown failure"s. This is basically
what Evolution startup looks like currently, since each component tries
to connect to the wombat as it's starting. Launching evolution fairly
reliably triggers the problem on some machines, but it only rarely
happens on others. (Probably processor speed/RAM related).


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. But making _server_by_forking_ not
use a main loop seems to cause multiple oafds (probably it makes it not
respond to CORBA_object_non_existent?)

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...)

-- Dan