Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!nrl-cmf!ames!oliveb!amiga!jimm
From: jimm@amiga.UUCP (Jim Mackraz)
Newsgroups: comp.sys.amiga
Subject: Re: Finishing up YAIP (Yet Another Input Handler), Need info.
Message-ID: <2094@amiga.UUCP>
Date: 11 May 88 18:13:08 GMT
References: <8805110206.AA19547@cory.Berkeley.EDU>
Reply-To: jimm@cloyd.UUCP (Jim Mackraz)
Organization: Commodore-Amiga Inc, Los Gatos CA
Lines: 56

In article <8805110206.AA19547@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes:
):By the way, it is probably not a good idea for programs to call Intuition
):functions (such as SetPrefs) from an input handler.  I can identify problems
):that might occur with locking, and there are probably others.  My
):intuition helper (IHelp) has input device signal or message a normal
):application task which calls Intuition for move windows and so on.  I bet 
):yours does the same.
):
):	jimm
)
)	Right.  I was calling SetPrefs() from a slave task ... the input
)handler simply Signal()d it.  However, I *am* calling WindowToFront(),
)WindowToBack(), WindowToBack(), and WhichLayer() from my handler.  Is
)that OK?  I was under the impression that intuition doesn't depend on
)input device timer ticks to be able to execute such operations.
)
)					-Matt

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.

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.

The fix for this will be in the Intuition() input handler.  Now, if this
and similar situations don't happen to arise because of the specifics
of your user interface, you're off the hook, for now.  I think you
can appreciate that the general advice must stand, though.  "Don't
call Intuition from the input.device task."  If it works for you, and you
would'nt mind updating your software if it stops working in a future
release, feel free to use whatever works.  No police action here, just
no guarantees.

Anyway, I'm still interested in hearing (maybe email) you general comments
on input handlers.  Have you looked at Commodities?  My claim is that
it should make your application trivial to write, and further that the
examples using it (in this case autopoint2) have something to offer.
Current version was written with a future performance tune in mind (which
I am about to start on), but apart from performance, I'm wondering what
it might lack.

	jimm

-- 
	Jim Mackraz, I and I Computing	  
	amiga!jimm	BIX:jmackraz
Opinions are my own.  Comments regarding the Amiga operating system, and
all others, are NOT to be taken as Commodore official policy.