Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga
Subject: Re: Finishing up YAIP (Yet Another Input Handler), Need info.
Message-ID: <8805120833.AA03541@cory.Berkeley.EDU>
Date: 12 May 88 08:33:31 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 44

>WhichLayer() is probably OK, but WindowTo*() isn't safe.  WhichLayer() is not
>an Intuition call, but may (or may not) lock layers, in which case
>it is dangerous.

	The main problem I face moving WindowTo*() to another task is that
there isn't much assurance the layer will stick around between determining
the window ptr and the other task actually doing the WindowTo*().  Right now,
I Forbid() BEFORE WhichLayer() and Permit() AFTER WindowTo*().  Now I
realize that the two calls can block and temporarily undo the Forbid(),
but WhichLayer() would only block getting its locks, and WindowTo*()
is hopefully sequenced inside Intuition (I don't know) so if intuition
blocks, somebody else doing a CloseWindow() won't get his call done before
mine.

	I can't move WhichLayer() to the other task because that will 
involve two task switches for every mouse event!

	Am I making sense?

>You may be lucking out,
>in that you don't call these functions when Intuition is in the middle of
>a prop gadget or something, but it MAY be that calling these functions
>from the input handler violate the locking order protocol that Intuition
>observes itself.  For example: we all know that when dragging an Icon,
>WindowToFront() will hang the system.  This is because workbench has
>the layers locked, and Intuition needs the layer locks to do
>WindowToFront(), so the input stops while Intuition waits for the locks,
>which WB won't free until it hears a mouse up.  Deadlock.

	Actually, that came up early testing.  I was calling WindowToFront()
*while* moving a workbench icon from a WB window to the backdrop.  The 
icon-move simply aborted... which is incorrect operation of course so the
release version of DMouse does not ever call WindowTo*() while the LMB is
being held down.  This probably saves my ass in a couple of cases.

>Anyway, I'm still interested in hearing (maybe email) you general comments
>on input handlers.  Have you looked at Commodities?

	Haven't looked at Commodities yet.  When I find the time...
If I find the time... Sigh.  Actually, if you think about it, the all-in-one
utilities probably load the input handler less than a whole bunch of one-in-one
utilities, commodities or not.

					-Matt