bobp@amiga.UUCP (Robert S. Pariseau) (11/14/85)
TITLE: Deadlock with AutoRequest() WARNING! We have had several people fall prey to a rather subtle deadlock situation involving AutoRequest() and (usually) the MENUVERIFY mode of Intuition. Other Intuition xVERIFY modes have similar potential for deadlock as well. AutoRequest() is the Intuition function used to build simple Requesters -- usually used for error processing. It blocks the requesting task until the user responds by selecting an exit gadget of the requester. AutoRequest() is built on top of BuildSysRequest() which, currently, makes a new window and installs your requester in it. MENUVERIFY is the Intuition menu handling mode which causes Intuition to send a message to your task if your window is the Active window and the user presses the Menu button (the right-hand button) on the mouse. Intuition will hold off doing all normal interactive processing until you reply to that message. Your reply indicates either that you've done any clean-up processing and Intuition can go display the menu, or that you want Intuition to ignore this menu request and let you handle the Right Mouse Button (RMB) yourself this time. Your delay before replying should be short because the system appears hung to the user until you reply to Intuition. You must NOT call AutoRequest() while MENUVERIFY is in effect in any window controlled by your task. If you do so, and if your window becomes the Active window, then if the user presses the Menu button you will be in a deadlock. Your task can't procede because the user hasn't selected an exit gadget on the Requester. The user can't select that gadget because Intuition is stuck in MENUVERIFY waiting for your task to reply. Your task can't reply because it's blocked behind the Requester. The subtlety is that AmigaDOS may generate an AutoRequest() FOR YOU if an I/O error happens during an AmigaDOS call. If an I/O error occurs during an AmigaDOS I/O call, AmigaDOS looks at the pr_WindowPtr field of the Process structure for the process that generated the call. [An AmigaDOS Process is an EXEC Task plus a little extra context. See the dosextens.h or dosextens.i include files for info.] If that field is -1, then AmigaDOS returns the error to the requesting process in the normal fashion. If that field is >=0, then AmigaDOS puts up a system requester using the AutoRequest() facility. If pr_WindowPtr is 0, that requester is put up in a new window in the Workbench screen. If pr_WindowPtr is positive, then it is interpreted as a pointer to a Window structure -- usually the control window for your program. In the current implementation, AmigaDOS puts up the requester in a new window in the same screen as the specified window. Certain unlikely I/O errors are detected so deeply in the file system that their requesters can ONLY appear in the Workbench screen even if you have specified a window. The pr_WindowPtr field is inherited from your process creator. Normally it's 0 when your process starts. If you change the field, you must be sure to change it back before your program exits. This is because you may be running as a co-routine of a CLI in the CLI process context. If you leave the pointer set to a window that you've just closed, the CLI will probably crash the system the next time it gets an I/O error. Not all I/O errors will generate requesters. The ones that do are the ones that the user can be expected to correct. These include Write Protected disks and Wrong Disk in drive. For more information on this processing, see the AmigaDOS Technical Reference Manual chapter on DOS Data Structures. The upshot of all this is that you shouldn't do AmigaDOS I/O calls while you have MENUVERIFY set and a pr_WindowPtr of other than -1. If you do, there is a chance that AmigaDOS will be forced to put up a system requester. In that case, if the user is so unfortunate as to hit the Menu button, while your window is the Active window, you will be in deadlock. Note that if you intend to do ALL your own Right Mouse Button processing, you can set the RMBTRAP flag in your Window structure without concern about deadlocks. The value of the MENUVERIFY stuff is limited to those cases where you WANT Intuition to do Menu processing, but you don't want it to do so just now. For more information on all of this refer to the manual Intuition: The Amiga User Interface.