From: heinz@edohwg.UUCP (Heinz Wrobel)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Debugging a filesystem handler...
Date: 1 Sep 92 19:35:16 GMT
Organization: Edotronik GmbH

In article <1992Aug31.061928.18053@softway.sw.oz.au> peterc@suite.sw.oz.au (Peter Chubb) writes:
>Does anyone know why this no longer works?

You may not startup directly or indirectly other handlers before you reply
to your startup packet with V37. Maybe that's the problem.

I forward this info to help:

>debatz@obsmeu.UUCP (B. de Batz) writes:
>>I have a strange problem, related, I think, with some new semaphore
>>in 2.x
>
>	 Yup.
>
>>I am writing a handler, and in order to debug it, I create, into it, a process
>>(following an old M. Dillon example) with CreateProc() .
>>In this process I open a debugging window with
>>
>> fh = Open("CON:0/0/640/100/debugwindow", MODE_NEWFILE);
>
>	 You cannot do an access which starts another handler until you reply
>your initial packet.  Of course, once you reply the initial packet you may
>get packets coming into your msgport, so it's not safe after that either.
>(The reason for the semaphore was to stop the old "two copies of ram: get
>started if you're quick" bug.)
>
>	 The solution is that there are 2 new globvec types (1 for BCPL-style
>handlers (globvec = -3), 1 for C-style handlers (globvec = -2)).  These
>don't grab the semaphore, but they require that your handler use forbid-locking
>around the setting of dol_Task.  If you don't set dol_Task, there's no
>problem.  The locking required is:
>
>	 Forbid();
>	 if (dev->dol_Task == NULL)
>		 dev->dol_Task = MyMsgPort;
>	 else
>		 // handler already started, return packet with success
>		 // and then exit!
>	 endif
>	 Permit();
>
>	 NOTE: under 1.3, dos didn't look at dol_Task if it started the process,
>it assumed if the packet succeeded that the process message port was what to
>send to.  This means that under 1.3 you must just either set dol_Task
>regardless of any value already there, or fail the startup packet if dol_Task
>is set already.
>
>	 There is another (>= 2.04) solution:  If you set dp_Arg4 (yes, put
>a return value in an arg), it will use that for the message port to send to.
>The "what message port to send to" algorithm is basically this:
>
>/* use either port passed back in arg4 or dol_Task (if set) */
>/* This allows handlers to keep their process port for sync */
>/* Dos I/O.						     */
>
>	 if (pkt->dp_Arg4)
>		 task = (struct MsgPort *) pkt->dp_Arg4;
>	 else if (node->dol_Task)
>		 task = node->dol_Task;
>	 else
>		 task = &(process->pr_MsgPort);
>
>	 Once again, the dp_Arg4 trick will not work in <V37.  It's primarily
>useful for handlers that do not set dol_Task (such as console and port
>handlers), so that they can do normal synchronous dos IO inside their handler
>(though be careful of that semaphore before your reply the startup message...)
>
>--
>A Novice asked the master: "What is the true meaning of programming?"  The
>master replied: "Eat when you are hungry, sleep when you are tired, program
>when the moment is right."  - The Zen of Programming
>-
>Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
>{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup
>Disclaimer: Nothing I say is anything other than my personal opinion.


>				- Peter Chubb

--
Heinz Wrobel, Edotronik GmbH (ECG018)
FAX +49 89 850 51 25 / TEL +49 89 850 25 20 (HOME!&VOICE, sometimes...)