Re: Actually looking at the code - why init oafd

[Maciej Stachowiak <mjs noisehavoc org>]

On 06Sep2001 10:55PM (-0400), Michael Meeks wrote:
> 
> Hi George,
> 
> On Thu, 30 Aug 2001, George wrote:
> > oafd is NOT started on program init, gconfd is not started on program
> > init.  No CORBA calls are made.
> 
>         AFAIR the oafd start on program init was an attempt to get round
> issues with idle handlers and activation; inasmuch that liboaf does
> something like:
> 
> user:           do_some_oaf_call
> liboaf:         get_activation_server
>                 fork_server
>                 g_main_loop_iterate and listen to GIOChannel for IOR
> user_idle:      do_some_oaf_call
>                 get_activation_server
>                 fork_server ....
> 
>         Which sucks. Clearly there are several possible solutions to this,
> one of which I think was initializing oaf at app startup.

liboaf uses an inferior main loop which _only_ listens to the channel
that the IOR might come in on, so it should not dispatch idle handlers
set on the app's main loop. Unless I am wrong about how the glib
main-loop code works.

I invite review of the code in bonobo-activation-fork-server.c (which
I did not write) by someone who is an expert in this area.
 
>         Perhaps this re-enterancy should be fixed inside bonobo-activation
> by using either a custom mainloop there - or possibly the linc mainloop -
> since then we can still get fun CORBA re-enterancy issues :-)

bonobo-activation already uses a custom mainloop there. Search for the
string `mloop' in that file. I believe this main loop will not even
dispatch incoming CORBA calls, which is OK because
bonobo-activation-server will not make any outgoing CORBA calls on
startup, and certainly not back to the app.

Regards,

Maciej