Subject: Re: Files-that-are-commands.
To: None <rkr@rkr.kcnet.com>
From: Phil Nelson <phil@cs.wwu.edu>
List: netbsd-help
Date: 01/12/2000 08:52:30
> * Unless I modify the system boot scripts, I will have to at least
>   logon to start the daemon.  (Supposing that I want the appearance
>...

No, you won't have to modify system boot scripts.  Use the cron "@reboot"
entry to restart something at reboot to multi-user mode.  

> * If two readers access the pipe at the same time, what happens?
>   Is the pipe busy?  Do they get bytes/lines in round-robin?
>...

My experience with this was that each open for reading was paired with
an open for writing.  The first process to reach the open will block
until the matching open happens.  Look at the following:

---->~/JUNK
nooksack[275]$ cat junk &
[1] 16708

---->~/JUNK
nooksack[276]$ cat junk &
[2] 16712

---->~/JUNK
nooksack[277]$ echo First > junk
First
[1]-  Done                    cat <junk

---->~/JUNK
nooksack[278]$ echo Second > junk
Second
[2]+  Done                    cat <junk

---->~/JUNK
nooksack[279]$ ls -l junk
prw-r--r--  1 phil  csfac  0 Jan 12 08:40 junk

Now doing it in the opposite way (writes first) causes something strange,
but this shouldn't be a problem for your situation.

---->~/JUNK
nooksack[283]$ echo First > junk &
[1] 16718

---->~/JUNK
nooksack[284]$ echo Second > junk &
[2] 16719

---->~/JUNK
nooksack[285]$ cat junk
First
Second
[1]-  Done                    echo First >junk
[2]+  Done                    echo Second >junk


I don't know if this is a situation where cat opens junk twice or
ignores the end of file or what.  

> * The pipe-filling command normally starts ``whenever'' rather
>   than when the pipe is opened for reading.  A subtle point, but
>   date-/time-sensitive actions (or ``current status'' outputs)
>   will have problems.  Of course, if the fifo is suitably blocked
>   on write until there's a reader, one can wrap the ``real'' program
>   in a script that emits a blank line into the pipe, first.
>
> * If the daemon dies, readers can end up stalled indefinitely.

It seems a simple daemon as follows would be very similar to what you want
and not likely to die:

   while (1) {
      f=fopen (namedpipe,"w");  /* blocks until an open for reading of the pipe */
      if (fork() == 0) {
	/* Time is after open for reading... */
	WriteWhatYouWant(f);
	exit(0);
      }
      fclose(f);
   }

You will of course have to make sure the daemon waits on dead children processes,
but that is easy.

-- 
Phil Nelson                    NetBSD: http://www.netbsd.org
e-mail: phil@cs.wwu.edu        Coda: http://www.coda.cs.cmu.edu
http://www.cs.wwu.edu/~phil