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 _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers