Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!asente
From: asente@decwrl.dec.com (Paul Asente)
Newsgroups: comp.windows.x
Subject: Re: Xt Problem [XtDispatchEvent()]
Message-ID: <1093@bacchus.dec.com>
Date: 17 Feb 89 01:34:14 GMT
References: <8902161223.AA01554@tub.UUCP>
Organization: DEC Western Software Lab
Lines: 45

In article <8902161223.AA01554@tub.UUCP> net@TUB.BITNET (Oliver Laumann) writes:
>> > XtDispatchEvent() is not re-entrant.
>>
>> According to Paul Asente, XtDispatchEvent is fully reentrant in X11R3.
>
>But it isn't.

Well, sort of.

I the R2 intrinsics, XtDispatchEvent wasn't at all reentrant.  This meant
that if you were in the middle of some event handler or action procedure
and you decided to go into recursive event handling, you were completely
hosed.  The R3 intrinsics fixed this, so you could call XtDispatchEvent
recursively.

But there's still the problem of the destroy list.  The intrinsics do a
two-phase destroy process so your widgets don't vanish out from under you
at inconvenient times, making it much easier to call XtDestroyWidget from
almost anywhere.  This entails keeping a list somewhere of the widgets
that need to be destroyed, and it has to be global.

Also, in earlier versions of the intrinsics, the second phase of destroy
wasn't invoked until the beginning of the next check for X events.  This
meant that sometimes the destroyed widgets hung around for a very long
time before actually going away.  We decided it needed to be moved to the
end of the dispatch procedure.

But this presented a problem.  If you were in a recursive dispatch, and
just deleted everything on the destroy list at the end of XtDispatchEvent,
you might destroy some things from earlier dispatches that weren't yet
safe to destroy.  So XtDispatchEvent creates a stack of destroy lists and
just destroys those widgets for the current event dispatch.  The easiest
way to do this was to use local variables and the call stack.

If you can provide us with a version of XtDispatchEvent which still
provides this functionality and is more reentrant, I'm sure we'd be glad
to take it.

>Oh, by the way, the line preceding the one quoted above in Event.c
>is a comment reading "This is pretty gross.".

Now you know why...

	-paul asente
	    asente@decwrl.dec.com	decwrl!asente