home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / amiga / programm / 13101 < prev    next >
Encoding:
Internet Message Format  |  1992-09-07  |  6.1 KB
  1. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!uvaarpa!adastra!mbs
  2. From: mbs@adastra.cvl.va.us (Michael B. Smith)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: More GADTOOLS questions...
  5. Distribution: world
  6. Message-ID: <mbs.0y3c@adastra.cvl.va.us>
  7. References: <mbs.0xis@adastra.cvl.va.us> <34908@cbmvax.commodore.com>
  8. X-NewsSoftware: GRn 1.16f (beta) by Mike Schwartz & Michael B. Smith
  9. Date: 4 Sep 92 22:46:55 EDT
  10. Organization: Private UUCP Node
  11. Lines: 132
  12.  
  13. In article <34908@cbmvax.commodore.com> peter@cbmvax.commodore.com (Peter Cherna) writes:
  14. > In article <mbs.0xis@adastra.cvl.va.us> mbs@adastra.cvl.va.us (Michael B. Smith) writes:
  15. > >V37 of gadtools.library has some weirdnesses when GT messages get queued up.
  16. > >It tends to cause the machine to lock up. GRn opens a 1x1 requester whenever
  17. > >it is "busy", and uses windows to simulate requesters.
  18. >
  19. > I don't think so.  There are no known problems with V37 gadtools and
  20. > queuing of messages.  Care to elaborate?  Better yet, send a bug report
  21. > with sample code please.
  22.  
  23. Sure. I'll also forward a copy of this to bugs@cbmvax.commodore.com. If I've
  24. got a bug, I'm willing to have help squashing it. Thanks.
  25.  
  26. Simplistically, GRn opens its main window on either a user-specified public
  27. screen, the default public screen, or a custom screen created by GRn (checked
  28. in that order) whichever it can find large enough for its display ("large
  29. enough" can be modified by the user, but is normally 640x400).
  30.  
  31. The window is filled with gadtools gadgets (buttons, checkboxes, listviews,
  32. text gadgets and a cycle gadget). Whenever an event causes WaitPort() to
  33. return, an EventHandler() routine is called, thusly:
  34.  
  35.         while (mode = ARTICLE_MODE) {
  36.                 WaitPort (mainWindow->UserPort);
  37.                 EventHandler (mainWindow, ProcessGadget, IDCMPFunc, NULL);
  38.         }
  39.  
  40. EventHandler() loops on GT_GetIMsg(), copies the message into a local
  41. IntuiMessage, does the GT_ReplyIMsg(), and then calls the appropriate
  42. routines to process the message. Note that we only use the legal pieces
  43. of the IntuiMessage: msg->Class, msg->Code, and msg->IAddress (to get
  44. GadgetID for GADGETUP and GADGETDOWN).
  45.  
  46. This is the EventHandler() routine (45 lines):
  47.  
  48. void    EventHandler (window, handleFunc, idcmpFunc, refreshFunc)
  49. WINDOW  *window;
  50. void    (*handleFunc)();
  51. void    (*idcmpFunc)();
  52. void    (*refreshFunc)();
  53. {
  54.         IMSG    *m, msg;
  55.  
  56.         while (m = GT_GetIMsg (window->UserPort)) {
  57.                 msg = *m;
  58.                 GT_ReplyIMsg (m);
  59.  
  60.                 switch (msg.Class) {
  61.                         case IDCMP_INTUITICKS:
  62.                                 break;
  63.  
  64.                         case IDCMP_MOUSEMOVE:
  65.                                 MouseMove (handleFunc, &msg);
  66.                                 break;
  67.  
  68.                         case IDCMP_GADGETUP:
  69.                                 GadgetUp (handleFunc, &msg);
  70.                                 break;
  71.  
  72.                         case IDCMP_GADGETDOWN:
  73.                                 GadgetDown (handleFunc, &msg);
  74.                                 break;
  75.  
  76.                         case IDCMP_REFRESHWINDOW:
  77.                                 GT_BeginRefresh (window);
  78.                                 if (refreshFunc)
  79.                                         (*refreshFunc)();
  80.                                 GT_EndRefresh (window, TRUE);
  81.                                 break;
  82.  
  83.                         default:
  84.                                 if (idcmpFunc)
  85.                                         (*idcmpFunc)(&msg);
  86.                                 else
  87.                                         DefaultIDCMPFunc (window, &msg);
  88.                                 break;
  89.                 }
  90.         }
  91.         return;
  92. }
  93.  
  94. The symptom seen occurs when a user clicks on a button gadget before GRn has
  95. finished processing the prior choice. GRn will lock up. The system will not
  96. crash, but GRn will lock up. JM (ps command) reports no further processor
  97. usage (and yes, I've tried it without JM in the system).
  98.  
  99. It can still happen, and as a matter of fact, does happen on the currently
  100. released version of GRn (1.16e) as I broke the requester disable that was
  101. being used (off by one error in a counter). While in Article Mode, click on
  102. "Next Group" two or more times very quickly (it may help to be on an
  103. unaccelerated machine....). GRn will update to the immediately next group,
  104. and then freeze.
  105.  
  106. Mike Schwartz had indicated to me that CBM was familiar with this issue.
  107.  
  108. > >The problem with real requesters is that GT's aren't locked out, unless they
  109. > >are explicitly disabled (not a chance you'd do that for speed purposes if you
  110. > >have more than one). So, if the user goes clicking away around the screen,
  111. > >you've got a hung machine....(it is quite possible that Myke or I did something
  112. > >wrong in GRn -- but we don't think so, and no one has pointed it out to us).
  113. >
  114. > Real requesters DO lock out all gadgets in the parent window, including
  115. > GadTools gadgets.  Unless you're trying to get smart with LockLayer() or
  116. > LockLayerInfo() or LockIBase(), there are no known ways to provoke a
  117. > deadlock in Intuition without there being a coding error in the application.
  118. > We sought out an annihilated all such problems prior to the release of 2.04.
  119.  
  120. I was imprecise. (BTW, we don't use Lockxxx() at all.) I haven't seen this
  121. personally, it was hearsay from a usually reliable source.   :)
  122.  
  123. Hmm. Does that statement also apply to EasyRequest()?
  124.  
  125. This is Mike's original description of the problem from an early CHANGES file:
  126.  
  127.         Added code in article mode to open 1x1 requester (disable gadgets,
  128.         IDCMP) during processing of events.  This should prevent people from
  129.         causing intuition/gadtools from queueing up bunches of events.
  130.         Apparently there is a bug in one or the other if too many events get
  131.         queued.
  132.  
  133. > Of course, we'd be interested in any useful information to the contrary...
  134.  
  135. I hope this is sufficient to lead in the right direction. Either for me to
  136. correct GRn, or...
  137.  
  138. > --
  139. > Peter Cherna, User Interface Development Group, Commodore-Amiga, Inc.
  140. > {uunet|rutgers}!cbmvax!peter    peter@cbmvax.commodore.com
  141.  
  142. --
  143.   //   Michael B. Smith
  144. \X/    mbs@adastra.cvl.va.us  -or-  uunet.uu.net!virginia.edu!adastra!mbs
  145.