Path: utzoo!attcan!uunet!garfield!john13
From: john13@garfield.MUN.EDU (John Russell)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Finding The Workbench Screen
Message-ID: <5034@garfield.MUN.EDU>
Date: 14 Dec 88 02:52:22 GMT
References: <1982@van-bc.UUCP> <7796@well.UUCP> <13231@ncoast.UUCP> <7907@well.UUCP>
Reply-To: john13@garfield.UUCP (John Russell)
Organization: Memorial University of Newfoundland
Lines: 59

In article <7907@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes:
>
>	If you're working on DigiPaintII, then you should be aware that
>using Forbid/Permit is not *neccesarily* the correct way to inspect public
>system structures.  I noticed GrabANIM doing the same thing with
>IntuitionBase, and a big bell went off in my head (JimM's words can be
>pretty infectious, you know...).
>
>	The correct way to look at IntuitionBase is to first call
>LockIBase().  

Now I've heard that too, but I've never seen a decent explanation of its
side-effects that would allow me to make any sort of safe use of it.
Incidentally, the same is true of GetScreenData until Chuck McManis's
article a few days ago. I notice the parameter to LockIBase in the 1.3
fd files is listed as "don't know".

Almost every time I've wanted to do something Intuition-related and
used LockIBase I've run into complete system freezeups. Forbid, which
does something similar, has done this on occasion but always it was
possible to track down the cause to something in my code and fix it.

For instance, let's say I want to...

locate window in system list (IntuitionBase->FirstWindow, etc).
ActivateWindow it
wait until it becomes active
twiddle it

For maximum safety it seems like all this should be a critical section:
the window list could be corrupted while I'm scanning it, and anytime
after I find it until I finish twiddling it the task which owns it might
close it.

If I use Lock/UnlockIBas around it, I know the ActivateWindow will cause
total lockup due to its asynchronous nature (I guess the input handler
gets stuck trying to modify IntuitionBase?). I'm pretty sure most of the
other twiddles I'd like to do will also run into the same problem. If
memory serves me correctly I've had lockups due to _other_ programs
popping up "insert disk" requesters or DMouse/WKeys et al doing layer
operations while trying out code that Locked IBase.

Forbid may give you less of a guarantee that the system will not be in an
inconsistent state, but what is the proper way to do anything more than a
trivial operation (say flipping a pointer) with LockIBase? Unlike many of
the other points on the Amiga learning curve (device io, superbitmap
manipulation, wb arg parsing) there don't seem to be any useful sources
that deal with it.

That might be a point to consider when adding new functions to 1.4 -- a
programmer's sample disk showing how to _properly_ use all the new goodies,
such as there were in the early days when every feature or function call
was an unknown quantity.

John
-- 
"The sinuous roots meshed together... the sun-dappled leaves... the arching
 branches... and put it all together? Nothing! Icky, icky tree!"
		    -- something like that anyway; from "The Kids in the Hall"