From: mbs@adastra.cvl.va.us (Michael B. Smith)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: More GADTOOLS questions...
Distribution: world
X-NewsSoftware: GRn 1.16f (beta) by Mike Schwartz & Michael B. Smith
Date: 4 Sep 92 22:46:55 EDT
Organization: Private UUCP Node

In article <34908@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes:
> In article <mbs.0xis@adastra.cvl.va.us> mbs@adastra.cvl.va.us (Michael B. Smith) writes:
> >V37 of gadtools.library has some weirdnesses when GT messages get queued up.
> >It tends to cause the machine to lock up. GRn opens a 1x1 requester whenever
> >it is "busy", and uses windows to simulate requesters.
>
> I don't think so.  There are no known problems with V37 gadtools and
> queuing of messages.  Care to elaborate?  Better yet, send a bug report
> with sample code please.

Sure. I'll also forward a copy of this to bugs@cbmvax.commodore.com. If I've
got a bug, I'm willing to have help squashing it. Thanks.

Simplistically, GRn opens its main window on either a user-specified public
screen, the default public screen, or a custom screen created by GRn (checked
in that order) whichever it can find large enough for its display ("large
enough" can be modified by the user, but is normally 640x400).

The window is filled with gadtools gadgets (buttons, checkboxes, listviews,
text gadgets and a cycle gadget). Whenever an event causes WaitPort() to
return, an EventHandler() routine is called, thusly:

        while (mode = ARTICLE_MODE) {
                WaitPort (mainWindow->UserPort);
                EventHandler (mainWindow, ProcessGadget, IDCMPFunc, NULL);
        }

EventHandler() loops on GT_GetIMsg(), copies the message into a local
IntuiMessage, does the GT_ReplyIMsg(), and then calls the appropriate
routines to process the message. Note that we only use the legal pieces
of the IntuiMessage: msg->Class, msg->Code, and msg->IAddress (to get
GadgetID for GADGETUP and GADGETDOWN).

This is the EventHandler() routine (45 lines):

void    EventHandler (window, handleFunc, idcmpFunc, refreshFunc)
WINDOW  *window;
void    (*handleFunc)();
void    (*idcmpFunc)();
void    (*refreshFunc)();
{
        IMSG    *m, msg;

        while (m = GT_GetIMsg (window->UserPort)) {
                msg = *m;
                GT_ReplyIMsg (m);

                switch (msg.Class) {
                        case IDCMP_INTUITICKS:
                                break;

                        case IDCMP_MOUSEMOVE:
                                MouseMove (handleFunc, &msg);
                                break;

                        case IDCMP_GADGETUP:
                                GadgetUp (handleFunc, &msg);
                                break;

                        case IDCMP_GADGETDOWN:
                                GadgetDown (handleFunc, &msg);
                                break;

                        case IDCMP_REFRESHWINDOW:
                                GT_BeginRefresh (window);
                                if (refreshFunc)
                                        (*refreshFunc)();
                                GT_EndRefresh (window, TRUE);
                                break;

                        default:
                                if (idcmpFunc)
                                        (*idcmpFunc)(&msg);
                                else
                                        DefaultIDCMPFunc (window, &msg);
                                break;
                }
        }
        return;
}

The symptom seen occurs when a user clicks on a button gadget before GRn has
finished processing the prior choice. GRn will lock up. The system will not
crash, but GRn will lock up. JM (ps command) reports no further processor
usage (and yes, I've tried it without JM in the system).

It can still happen, and as a matter of fact, does happen on the currently
released version of GRn (1.16e) as I broke the requester disable that was
being used (off by one error in a counter). While in Article Mode, click on
"Next Group" two or more times very quickly (it may help to be on an
unaccelerated machine....). GRn will update to the immediately next group,
and then freeze.

Mike Schwartz had indicated to me that CBM was familiar with this issue.

> >The problem with real requesters is that GT's aren't locked out, unless they
> >are explicitly disabled (not a chance you'd do that for speed purposes if you
> >have more than one). So, if the user goes clicking away around the screen,
> >you've got a hung machine....(it is quite possible that Myke or I did something
> >wrong in GRn -- but we don't think so, and no one has pointed it out to us).
>
> Real requesters DO lock out all gadgets in the parent window, including
> GadTools gadgets.  Unless you're trying to get smart with LockLayer() or
> LockLayerInfo() or LockIBase(), there are no known ways to provoke a
> deadlock in Intuition without there being a coding error in the application.
> We sought out an annihilated all such problems prior to the release of 2.04.

I was imprecise. (BTW, we don't use Lockxxx() at all.) I haven't seen this
personally, it was hearsay from a usually reliable source.   :)

Hmm. Does that statement also apply to EasyRequest()?

This is Mike's original description of the problem from an early CHANGES file:

        Added code in article mode to open 1x1 requester (disable gadgets,
        IDCMP) during processing of events.  This should prevent people from
        causing intuition/gadtools from queueing up bunches of events.
        Apparently there is a bug in one or the other if too many events get
        queued.

> Of course, we'd be interested in any useful information to the contrary...

I hope this is sufficient to lead in the right direction. Either for me to
correct GRn, or...

> --
> Peter Cherna, User Interface Development Group, Commodore-Amiga, Inc.
> {uunet|rutgers}!cbmvax!peter    peter@cbmvax.commodore.com

--
  //   Michael B. Smith
\X/    mbs@adastra.cvl.va.us  -or-  uunet.uu.net!virginia.edu!adastra!mbs