Re: Actually looking at the code - why init oafd
- From: Maciej Stachowiak <mjs noisehavoc org>
- To: Michael Meeks <michael ximian com>
- Cc: George <jirka 5z com>, Maciej Stachowiak <mjs eazel com>, gnome-2-0-list gnome org
- Subject: Re: Actually looking at the code - why init oafd
- Date: Fri, 7 Sep 2001 00:47:06 -0700
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
> g_main_loop_iterate and listen to GIOChannel for IOR
> user_idle: do_some_oaf_call
> 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.
] [Thread Prev