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