Re: bonobo-activation bug ...

[Michael Meeks <michael peabody ximian com>]

Hi Maciej,

On Thu, 29 Nov 2001, Maciej Stachowiak wrote:
> My plan for dealing with this problem generally was to detect when the
> inferior main loop in server_by_forking is running inside another one
> that is trying to activate the same server, and if so, continue the
> original activation somehow instead of firing off a whole new server,
> and return the same server object both times. This will also address
> the race condition with multiple component servers getting activated
> sometimes as well.
>
> The changes should be mostly localized to server_by_forking I think.

        A nice idea :-) indeed I tried this approach - however; the code
that checks for the server, and registers it that needs to be re-executed
to detect a possible race is well lower on the stack - and you can't
execute it without significantly abstracting the code; We nee to
virtualize the process of activation and instantiate an object per
activation that we can jam on a queue with a virtual 'register_result'
method and a virtual 'check_registered' method.

        Then when we detect that someone lower on the stack is activating
the same app name - we can wait until that is activate - force the
stacked register earlier - de-queue it, then check our local object to see
if that got registered and if not proceed with the activation [ different
env or whatever ].

        It'll need a chunky structural re-arrangement.

        However - the most immediate and embarassing problem can be
removed (most likely) by using the linc mainloop instead of the glib
mainloop for listening on the forked process for it's IOR; this should
stop any glib idle handlers kicking in until we're activated - perhaps; I
havn't checked this out in detail.

        Regards,

                Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot