Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!ucbvax!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Device Manager Mysteries
Message-ID: <7940@hoptoad.uucp>
Date: 11 Jul 89 03:54:57 GMT
References: <1128@granjon.UUCP>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 29

In article <1128@granjon.UUCP> ggr@granjon.UUCP (Guy Riddle) writes:
>Now consider one of the other drivers, say the AppleTalk .ATP one.  It takes
>up only one Unit Table slot so has only one queue.  How does it manage to
>handle multiple outstanding requests at the same time?  It obviously is
>able to start work on new requests before those preceding them in the
>Device Manager queue have finished (some, like PAP Tickles, stay around
>for a *long* time).
>
>Have I missed some trick to the Device Manager?  Some feature not mentioned
>in IM-II that allows a driver to process its queue in a different order?

Good question!  The exact details of this are not documented.  However,
you should notice that the request queue to any driver is simply a
normal Mac queue.  Provided you take basic precautions against
non-synchronization with requests from a higher interrupt level, the
driver can pretty much do whatever it wants with the queue.  All that's
required is treating the parameter blocks correctly -- calling
completion routines, setting 1 while in progress and noErr or an error
code when done, etc.  I would imagine that multiple NBP requests in the
new driver are handled by simply scanning down the whole queue and
handling all pending requests rather than the one for which the driver
got called.  This is somewhat hairy stuff, but then, this code is
written by Apple and they can get away with it.  Your mileage may
vary.
-- 
Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com
Postal: 424 Tehama, SF CA 94103; Phone: (415) 495-2934

"Gorbachev is returning to the heritage of the great Lenin" - Ronald Reagan