Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!purdue!decwrl!ucbvax!hplabs!hplabsb!quan From: quan@hplabsb.UUCP (Suu Quan) Newsgroups: comp.unix.wizards Subject: Re: Spawning daemons. Message-ID: <4916@hplabsb.UUCP> Date: 24 Sep 88 00:44:41 GMT References: <6840003@hpcllcm.HP.COM> Organization: HP Labs, Manufacturing & Measurement Systems Lab, Palo Alto, CA Lines: 21 In article <6840003@hpcllcm.HP.COM>, pratap@hpcllcm.HP.COM (Pratap Subrahmanyam) writes: > The user processes communicate asyncronously whenever they please. This works > fine except for the fact that the daemon has to come on usually at boot time > of machine. > > This is a big problem if the daemon has to a lot of book-keeping work from > time to time, like communication statistics, and hence becomes a CPU hog. > Nicing it is one way. But is there another way to solve this problem ?? > > If the daemon need not be alive for too long 'before' the first client tries > to talk to it, then I have the following scheme. The first user, when he tries > to talk to the daemon finds the communication protocol not set up (like FIFO > files in /tmp) and then figures out that it is the first user and hence fires > the daemon up. Now it could die, leaving UNIX to make the undying child process > the child of root and hence a true daemon. Don't really know if this will solve your problem - because I don't really understand it -, but did you consider leaving 'inetd' to spawn your server daemon whenever there is a request for connection from a client ?