NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/sys/amiga/programm/13026

Internet Message Format | 1992-09-02 | 3.9 KB

Path: sparky!uunet!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbnewsc!cbfsb!att-out!pacbell.com!iggy.GW.Vitalink.COM!cs.widener.edu!dsinc!bagate!cbmvax!cbmehq!cbmger!edohwg!heinz
From: [e-mail] (Heinz Wrobel)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Debugging a filesystem handler...
Message-ID: <[e-mail]>
Date: 1 Sep 92 19:35:16 GMT
References: <[e-mail]>
Organization: Edotronik GmbH
Lines: 86

In article <[e-mail]> [e-mail] (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:

>[e-mail] (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, [e-mail]  BIX: rjesup
>Disclaimer: Nothing I say is anything other than my personal opinion.


>                - Peter Chubb

--
Heinz Wrobel, Edotronik GmbH (ECG018)
FAX [phone] / TEL [phone] (HOME!&VOICE, sometimes...)
Path: cbmehq!cbmger!edohwg![e-mail]
"It's good to have a mouse, it's faster if you can do without one..."
"He who doesn't develop with an A2024 doesn't know about font independent
 user interfaces..."