Path: utzoo!attcan!uunet!cbmvax!jesup
From: jesup@cbmvax.UUCP (Randell Jesup)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Finding The Workbench Screen
Message-ID: <5508@cbmvax.UUCP>
Date: 15 Dec 88 00:38:51 GMT
References: <1982@van-bc.UUCP> <7796@well.UUCP> <13231@ncoast.UUCP> <7907@well.UUCP> <5034@garfield.MUN.EDU>
Reply-To: jesup@cbmvax.UUCP (Randell Jesup)
Organization: Commodore Technology, West Chester, PA
Lines: 53

In article <5034@garfield.MUN.EDU> john13@garfield.UUCP (John Russell) writes:
>In article <7907@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes:
>>	The correct way to look at IntuitionBase is to first call
>>LockIBase().  

>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.

	Well, you're right that that operation is something you'ld like to
be critical, but it can't be right now.  The reason is that your call to
Intuition, ActivateWindow, is (a) deferred and put on a queue for intuition
to do later, and (b) requires intuition, running as input.device, to be
able to LockIBase itself.  Since you left it locked, it goes into a wait
which it never comes out of.

	Solution: UnlockIBase after ActivateWindow.  If it isn't your window,
you can't easily get notified that it's active (without evil magic with
IDCMP), so you should Delay() a bit, LockIBase, check if the window (a)
still exists, and (b) is now active, and if so then do your magic, else
go and Delay again.  Yes, this is polling, but you're trying to do a fairly
evil thing to someone else's window, so the system won't help you much.
Make sure you use the Delay()s, they'll reduce the load.  Also note that some
other program or the user might make the window inactive before you notice
it's active, so think about it.

>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.

	Mainly because the operations you want to do aren't in general
supported operations.  Some of the types of things you want to do will be
in 1.4, but not at the window level, only screens.  Jimm, want to comment?

-- 
You've heard of CATS? Well, I'm a member of DOGS: Developers Of Great Software.
Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup