[comp.unix.programmer] Global symbolic process names, anyone?

dag@kvatro.no (Dag H. Wanvik) (05/24/91)

I am trying to let several Unix processes be able to "address" each
other by mapping a symbolic name to a process id. I've so far found no
other way of doing this than using the global name space as
represented by the file system, letting each file contain the pid of
the process whose "name" is the file name. I could do this using
permanent files except I am not confident I will be able to delete
them when the processes terminate in an abnormal way. 
I know about tmpfile/tmpnam/tempnam, but I want a more direct way to
make a file temporary, if possible.

a) Is it possible to make any file temporary when creating it? (or by
setting a mode bit (undocumented?!). (I need to fully control the file
name, which is not possible using tmpfile and friends...)

b) Am I totally on the wrong track? Is there a better way to create a
global name map (symbol -> pid) functionality?

Any help woulf be much appreciated!

Dag
--

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dag H. Wanvik  ,   Senior Systems Engineer
Mailing address:   KVATRO AS, Pirsenteret, N-7005 Trondheim, NORWAY
Telephone      :   +47 7 520090
Fax	       :   +47 7 520140
Internet e-mail:   wanvik@kvatro.no [my VAX/VMS address]
          or   :   dag@kvatro.no    [my Unix address]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

mycroft@kropotki.gnu.ai.mit.edu (Charles Hannum) (05/28/91)

In article <DAG.91May24184648@freya.kvatro.no> dag@kvatro.no (Dag H. Wanvik) writes:

   a) Is it possible to make any file temporary when creating it? (or by
   setting a mode bit (undocumented?!). (I need to fully control the file
   name, which is not possible using tmpfile and friends...)

One idea is to have a creattmp() or some such function which simply
calls creat() and sticks the file in a list of temporary files.  You
could then define an atexit() function to do the cleanup.  (I'm not
quite prepared to include code right now.)

Hmmm.  Perhaps the addition of an O_TMP mode in the GNU library would
be prudent?  B-)