Re: GEP 12: Bonobo Unique Application

["Gustavo J. A. M. Carneiro" <gjc inescporto pt>]

  Hi, Michael,

  I am confident that including GEP 12 is good.  Whatever problems the
implementation may have, I'm sure they can be gradually fixed.

  Since you mention lifecycle issues, I must say I'm not sure what are
those issues, but there is a lifecycle related issue in libbonobo, in my
latest bonobo-activation extensions.
  The problem is in the following IDL method: 
	--------------
                RegistrationResult register_new (in  ImplementationID              iid,
                                                 in  Bonobo::ActivationEnvironment environment,
                                                 in  Object                        obj,
						 in  RegistrationFlags             flags,
                                                 out Object                        existing);
	--------------

  The new 'existing' output parameter returns the existing registered
object, if available.  However, it returns an existing reference.  It
doesn't ref() the returned object.  And we don't ref() it because it is
not a Bonobo_Object, it is a CORBA_Object.
  You think maybe we should narrow it to a Bonobo::Object
reference--since we *know* it is a Bonobo::Object--and ref() it before
returning the new reference to the caller?

  Unfortunately, even if we do ref() the object being returned, there is
still a race condition, that could happen in rare circumstances. 
Imagine the following scenario:
	- We have a factory process, that is currently serving one object
reference--a Bonobo::Application, for example--and quits when the number
of objects being served drops to zero.
	- At some point, two events take place in parallel:
		1. The reference count of the object being served by the factory drops
to zero, and the factory decides to quit;
		2. Another application instance calls register_new to register itself,
but receives the 'existing' object instead.

  Depending on the relative timings of events 1 and 2, the results could
be bad:
	o If the factory receives the new Bonobo::Object::ref() before deciding
to quit, all is well.
	o If the factory receives the new Bonobo::Object::ref() after deciding
to quit, but (obviously) before the b-a-s realizes the factory wants to
quit, then we have a serious problem, CORBA_COMM_FAILURE most likely.

  One possible solution would be to require factories to ask b-a-s if it
is OK to quit before quitting.  Or something like that.  Or we don't do
anything, since this problem is very unlikely to occur anyway.

Terminology:
b-a-s: bonobo-activation-server

A Seg, 2003-05-19 às 16:20, Michael Meeks escreveu: 
> Hi Havoc / Gustavo,
> 
> 	It seems this GEP's got rather delayed, and we're getting too close to
> the API/ABI freeze for comfort;
> 
> 	Thus - I think it'd be best to move to discussing / voting on this for
> inclusion now.
> 
> 	Personally - while I'm still unhappy as to how b-a-s deals with
> lifecycle issues [1], and there is plenty of scope for improvement there
> I don't think this impinges much on proceeding with gep-12.
> 
> 	So - I'm in favour of this: Havoc/Gustavo ?
> 
> 	Regards,
> 
> 		Michael.
> 
> [1] - and dramatically more unhappy that people are duplicating effort
> left and right fixing this in random other projects.

-- 
Gustavo João Alves Marques Carneiro
<gjc inescporto pt> <gustavo users sourceforge net>