Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-lcc!styx!ames!ucbcad!ucbvax!decvax!decwrl!sqm.dec.com!jmsynge From: jmsynge@sqm.dec.com (James M Synge, DTN 381-1545) Newsgroups: comp.sys.amiga Subject: Re: Servers, libraries, devices and handlers Message-ID: <9750@decwrl.DEC.COM> Date: Thu, 7-May-87 18:37:37 EDT Article-I.D.: decwrl.9750 Posted: Thu May 7 18:37:37 1987 Date-Received: Sat, 9-May-87 09:53:39 EDT Sender: daemon@decwrl.DEC.COM Organization: Digital Equipment Corporation Lines: 60 Mike Meyer writes: > The library/device > mechanism looks just about perfect, but there appears to be to much > overhead (for devices, anyway). What do you mean by too much overhead? With a device you could make an asynchronous server to which commands could be queued (a print service comes to mind). > I suppose I could create a > 1-entry-per-command library. Someone wanna comment on that? Another option would be to make a 1 entry library (actually 5 including the required Open, Close, Expunge and Reserved entries) which could dispatch to various internal routines by the name of the command you where executing. This would make it easy for you client to access the library with out having to worry about how many commands the current library supports. (Of course, I may not yet understand quite what you are using the server for, and what type of clients it has.) > There are lots of things floating around called "xx-handler". None of > the docs I can reach talk about these. Am I correct in assuming that > this is just a device under a different name? These are AmigaDOS handlers, which may be used on the command line (i.e. PRT: as opposed to printer.device). They may be acting as an interface to an exec device. > Some requirements: I'd like for the server half to continue to be > runnable in it's current mode, or at least compilable into that mode > without the #ifdef's getting to deep. Huh? Please repeat! I'm not at my most intuitive today (Amiga Humor :^) > Also, the server has state that > it'd be nice to keep around between open()s, if possible. Having it > vanish isn't a catastrophe, but having it not vanish is much better. This is fairly straight forward. When the memory allocator finds it self unable to satisfy a request, I beleive it asks all devices and libraries, etc. to get the h*ll out of memory. Its up to the expunge code of that object to decide what to do. A library typically will look at its open count and expunge itself it it is zero, otherwise it'll defer it till the count goes to zero. A similar thing is done in devices. So, as long as you've got enough memory, there should be no problem with the data staying around. Of course if you are short of memory, then getting rid of a library can help, so you shouldn't write your library so that it refuses to leave (impudent little library!). James Synge USENET: {decvax, ucbvax, allegra}!decwrl!sqm.dec.com!jmsynge ARPAnet: jmsynge%sqm.DEC@decwrl.DEC.COM #include "Ken Olsen can speak for Digital, not me!"