mwm@violet.berkeley.edu.UUCP (05/05/87)
I just finished building a server/client pair on the Unix model: The server gets started, and opens a public port. The client opens the port, and crams commands down it. In other words, I do a "run <server>", and can then do "<client> command", and everything works fine (actually, it's kinda cute issuing cli commands, and watching another window that you wouldn't expect to go through gyrations). This is all well and good, but I oughta be able to do better on the Amiga. What I'd like to do is arrange things so that when I run "<client> command", it causes the server to be loaded from disk (if needed), and then starts it. Flushing the server from memory if nobody has any oustanding requests is also desirable. The library/device mechanism looks just about perfect, but there appears to be to much overhead (for devices, anyway). I suppose I could create a 1-entry-per-command library. Someone wanna comment on that? 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? 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. 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. Of course, if I'm barking up the wrong tree, and there's an easy/obvious way to do this, I'd appreciate hearing about it. Thanx, <mike -- Take a magic carpet to the olden days Mike Meyer To a mythical land where everybody lays ucbvax!mwm Around in the clouds in a happy daze mwm@berkeley.edu In Kizmiaz ... Kizmiaz mwm@ucbjade.BITNET
jmsynge@sqm.dec.com (James M Synge, DTN 381-1545) (05/08/87)
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 <disclaimer.h> "Ken Olsen can speak for Digital, not me!"