Re: Another oaf race condition

[Maciej Stachowiak <mjs noisehavoc org>]

On 14Oct2001 04:18PM (-0400), Dan Winship wrote:
> 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).
> 

Hi Dan,

Can you reproduce this with any other components besides 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?

I always thought the point of the inferior main loop was to avoid
dispatching CORBA calls but I guess I misunderstood.

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

Yeah, that's probably one bad side effect of not dispatching CORBA
calls.
 
> 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.

 - Maciej