ggr@granjon.UUCP (Guy Riddle) (07/11/89)
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
tim@hoptoad.uucp (Tim Maroney) (07/11/89)
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