From: converse@expo.lcs.mit.edu (Donna Converse)
Newsgroups: fj.mail-lists.x-window
Subject: Re: X Toolkit Callback Order
Date: 9 Apr 92 00:14:50 GMT
Distribution: fj
Organization: X Consortium, MIT Laboratory for Computer Science

Message-Id: <9204081759.AA00754@excess.lcs.mit.edu>
             <vtqj4g+.nathan@netcom.com> 
Date: Wed, 08 Apr 92 13:59:32 EDT



> The X Toolkit Technical Reference Manual (O'Rielly & Assoc.) states that
> the function XtAddCallback() adds the specified callback to the
> end of the callback list.

The library specification does not describe the relative positions of the
newly added callback procedures and the preexisting callback procedures on 
the list.


> The X Toolkit Programming Manual shows by example (in section 3.4.2)
> that callbacks are called, in sequence, from the first entry in the list 
> to the last.

The libarary specification does not describe the order of execution of 
callback procedures from a list.


> My experience tells me that it works as these manuals indicate it should.

It is implemented that way in the code from the X Consortium.


> I have had a few people insist that callback invocation order cannot
> be gauranteed from one implementation to the next.

They're right, only because the library specification does not require
any particular invocation order.  But this isn't the point.  And it is
highly unlikely that someone will change the Intrinsics implementation
to invoke callbacks in some other order, unless they're a sadistic idiot.


>   Can one depend on callbacks (more than one registered for a single
> callback resource) being invoked in order they were added to the list.

The Intrinsics library can make no guarantees about the order of execution
of callback procedures from a callback list.  The interesting fact is that
both widget writers and application writers have access to the callback
lists, and either one or both can rearrange the contents and/or order of
the procedures in the list.   Therefore, the Intrinsics cannot guarantee
to either the application programmer or to the widget programmer that the
procedures that they registered for the callback list will be executed in
the same order that they were registered.  

As an example, every widget has a destroyCallback resource.  Many widgets
themselves register a callback on this list, and many applications also
register callbacks on this list.  Neither the application programmer nor
the widget writer is aware of what the other one is doing with the list.
The Intrinsics can guarantee nothing about the order of execution of the
callbacks on the list to either programmer.  And, most importantly,
the individual callback procedures should execute independently of each
other, in the sense that each has an independent functionality from
the other; particularly, functionality not dependent on the effects of
one callback executing before or after the other.

The situation is that the application programmer and the widget programmer
cannot be aware of each other, and therefore neither one can act as if
they have complete control over the callback list.   

In my own opinion, a widget which manipulates the contents of a callback
list should document the changes it makes if those changes could interfere
with an application programmer's use of the list.  For example, the Random
widget could deliberately shuffle the callbacks on its callback list upon
receipt of some random event - but it had better document this feature!
Someone else might argue that any widget could do this, and any application
programmer should be prepared for this at any time, but I would disagree
on the basis of principle.  On the basis of pure logic alone, however,
they are right.


Donna Converse