[g-a-devel]Re: ORBit2 event delivery

[Bill Haneman <bill haneman sun com>]

On Wed, 2002-06-12 at 11:15, Michael Meeks wrote:
> Hi Bill,
> 
> On Tue, 2002-06-11 at 19:17, Bill Haneman wrote:
> > I am wrestling with a problem.  I need to know, what does the ORB say
> > about the order of delivery of events to a given client?
> 
> 	The problem is ( for you ) I think that re-enterancy is garbling the
> order; ie. during the processing of emission a) emission b) re-enters
> and that must be finished before a) can be emitted ...
> 
> > In the case of AT, we must guarantee the order of delivery of many
> > events, and we're seeing events coming in re-ordered.  We expect that
> > when dealing with multiple clients, etc., but expect that the events
> > coming in from a specific client should stay ordered.
> > 
> > Is there anything we can do about this ?
> 
> 	cf. my other mail; I think the best soln' all round is to bin the use
> of ref counting.

Unfortunately I don't see this working for us, since there are common
cases where we create *lots* of accessible objects without backing
widgets (e.g. tables, etc).  The lifecycle of those objects must be
controlled by the requesting clients, which are remote.  It's also the
case that the ref()/unref() API is already public, it's hard to see how
going from public "must use ref counting" to "must not use ref counting"
is a very manageable thing to do.  Thus, though I think we've only begun
to discuss our options, I am pessimistic about the prospects for this
particular proposal.

-Bill

> > p.s. - don't say "no", 'cause that's not a possible solution... ;-)
> 
> 	:-) No ! [ only joking :-].
> 
> 		Michael.
> 
> -- 
>  mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot
>