Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!att!ulysses!granjon!ggr
From: ggr@granjon.UUCP (Guy Riddle)
Newsgroups: comp.sys.mac.programmer
Subject: Device Manager Mysteries
Message-ID: <1128@granjon.UUCP>
Date: 10 Jul 89 19:55:48 GMT
Organization: AT&T Bell Laboratories, Liberty Corner
Lines: 28

I've been trying to figure out how the Device Manager works and even after
poring over the Device Manager chapter (chapter 6 of Volume II) of
Inside Macintosh with a fine-tooth comb, some essential nuggets of truth
seem to have slipped through my fingers.

I've got the part that there are synchronous and asynchronous calls, which
specify whether or not the *caller* will be suspended until the call completes.
However, it seems that on the driver end of things, the queueing is first-in-
first-out with only one transaction in progress at a time.  The job stays
in the queue until the driver calls IODone, at which point it gets called to
start on the next transaction if there are more queued.  This explains why
the Serial Driver takes up 4 Unit Tables slots -- to enable it to have
a read and a write outstanding on each of the 2 ports concurrently.

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?

Inquiring minds want to know.

		=== Guy Riddle == AT&T Bell Laboratories, New Jersey ===
				   ggr@garage.att.com