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 ?