Re: heads-up on ORBit2 behavior under load

[Michael Meeks <michael ximian com>]

Hi Bill,

On Tue, 2002-06-11 at 23:15, Bill Haneman wrote:
> I am running into some significant SEGV-type problems in
> at-spi-registryd, and it's starting to look as though the root issues
> might lie in the ORB's (ORBit2) behavior under stress.

	Yes - I can well believe this. The problem is that if the event
consumer is doing more work than the event producer - the stack will
eventually blow - that is if it's doing CORBA calls that let new
incoming requests get processed.

> There is a buglet or something in gtk+ or maybe gail at the moment that
> causes lots of text events to be generated when switching between apps
> in gtk-demo.  As a result, leaning on the arrow keys in gtk-demo
> generates a storm of at-spi notify calls; in fact if you have keyrepeat
> on you can trigger a catastrophic failure in under a second.

	Yes - I can imagine - not good.

	Ok; so, there are various solutions one might suggest; the root problem
is of course, the unfortunate way we deal with oneway's and Bonobo
Unknown reference counting - which just sucks; sadly this not
particularly fixable, unless we move to a model where the lifecycle of
an accessible is controlled by an altogether different mechanism - such
as the lifecycle of the widget which it is associated with.

	So; potential fixes enumerated at the end.

> Not sure how to
> prevent this, but it seems as though at some point the ORB should block
> rather than continuing to push stuff onto the stack...


> Help tackling/diagnosing very much appreciated, this is prolly a stopper
> since we can't keep people from using keyrepeat ;-)

	Yes ;-)

> I have not logged a bug yet, awaiting suggestions from you as to
> where/how to classify it.

	Ok so here are some alternative solutionlets:

	* Make bonobo_object_dup_ref_async - this would (normally) not
	  allow a re-entering call to be processed, but would simply
	  blast a ref over the wire asynchronously. Trivial to write,
	  no API ramifications - theoretical possibility that the ref
	  might not arrive before the outgoing event [ + remote unref ]
	  occurs, resulting in remote accessibles being destroyed 
	  prematurely - possibly not so serious, should give it some 
	  thought.

	* Add an XSynchronize like API, to ensure that nothing re-enters
	  during a guarded call; thus the bonobo_object_ref stream 
	  before the event propagation would all be synchronous - this
	  should have no performance issues above what we have already,
	  and would stop events getting re-ordered as they can in the
	  current approach ( by re-enterancy ). It involves API 
	  additions to the ORB - and it's not clear how best to do this,
	  Mark is in favour of a client POA policy, but it'd need to be 
	  very rapidly settable, I prefer a simple C method etc.

	* Reduce the amount of ref/unref traffic we're doing, AFAIR we 
	  do something like:

		ref (a), ref (a), emit event x 2, unref (a);

	  which we could compress to: ref (a), emit_event x2 - beware of
	  ref-counting confusion doing that, the current approach is at
	  least clear. This would have the advantage of killing the 
	  problem for only a single listener / AT.

	* Bin ref/unref for Accessible lifecycle use - it hardly seems 
	  to make sense anyway; we have quite an acceptable lifecycle 
	  mechanism, slaved to the Gtk+ / AtkObject anyway, so - we 
	  could do bonobo_object_set_immortal on the objects and just
	  dispose of them when we're no longer interested. Thus the 
	  registry would save lots of CORBA traffic & re-enterancy 
	  points, and the clients wouldn't have to send ref/unrefs -
	  should save a huge amount of CORBA traffic, giving more speed,
	  require no new APIs, simplify the code, and ... well this is
	  my preferred approach as you can see ;-)

	So ...

	Any thoughts ?

		Michael.

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