Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!ux1.cso.uiuc.edu!resnick
From: resnick@cogsci.uiuc.edu (Pete Resnick)
Newsgroups: comp.sys.mac.programmer
Subject: Re: RAM DRVRs, resLocked, dNeedLock
Message-ID: <1991Jan23.034202.16680@ux1.cso.uiuc.edu>
Date: 23 Jan 91 03:42:02 GMT
References: <1991Jan22.230133.19377@midway.uchicago.edu>
Sender: news@ux1.cso.uiuc.edu (News)
Organization: University of Illinois at Urbana
Lines: 67

I think Charles gets this wrong. First let's see what's going on: A DRVR
will be a handle to the code to be executed. This handle will be part
of a record that the Device Manager keeps in the driver table. The code
must *always* be locked when the code is being executed (how horrible
it would be if executing code was moved in memory!!). Any time the
a Device Manager call is made, either by a program or by the Device
Manager itself with accRun, etc., the Device Manager will lock the
handle. Any time the code finishes, the Device Manager will be the
one to unlock it, unless you specifically tell it not to with dNeedLock.
Why would you not want your code unlocked?? If your code can be called
by other than the Device Manager, like a completion routine that you pass
to something that will complete later. The Device Manager will have no
warning to lock your code, so you have to tell it not to unlock it. So:

martin@cs.uchicago.edu writes:

>I'm unclear about the relationship between RAM DRVRs, resLocked, and
>dNeedLock.  Specifically:

>    Does a resLocked DRVR effectively have dNeedLock?
>    Does a dNeedLock DRVR effectively have resLocked?
>    Isn't a DRVR always locked anyway between OpenDriver and CloseDriver?

>My hypotheses are: Yes, No (not necessarily locked before OpenDriver and
>after CloseDriver), and Yes.  Now for some examples:

I think the answers should be no, no, and no. The Device Manager
should, as I understand it, attempt to unlock your driver after
exection unless you tell it specifically not to. The answer to the second
question is correct; the driver should be locked between Open and Close.
The answer to the third question is also no, as explained above.

>    The DRVR patches traps when opened and removes them when closed.
>    Use dNeedLock?

>    The DRVR patches traps when opened which remain when closed.
>    Use resLocked?

>    The DRVR does no patches.
>    Neither resLocked nor dNeedLocked are necessary?

Depends on what you mean by patches traps. If you mean that the driver
will load and lock *other* code to patch the traps, then no, it doesn't
need lock. If the driver will have its *own code* as the patches, then
clearly yes, since the patches may be called when the Device Manager
doesn't have you locked. And again, even if there are no patches, if
a driver routines can be called by something other than the Device
Manager, you will need to lock it.

>What all this is getting at is, if the DRVR needs resLocked or dNeedLock,
>how should it be handled so as to cause the least fragmentation to the
>heap?  I.e., after:

>    drvr := Get1Resource ('DRVR', id);

>If the DRVR is resLocked, then its placement in the heap seems somewhat
>random.  Would a MoveHHi before locking have been appropriate?

Doesn't loading a locked resource automatically do a MoveHHi anyway?

pr
--
Pete Resnick             (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet/ARPAnet/EDUnet  : resnick@cogsci.uiuc.edu
BITNET (if no other way) : FREE0285@UIUCVMD