Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!ucla-cs!ames!ptsfa!ihnp4!ihlpa!qix
From: qix@ihlpa.ATT.COM (Puckett)
Newsgroups: comp.sys.amiga
Subject: Re: Comments on the uniqueness of task & window id's
Message-ID: <4445@ihlpa.ATT.COM>
Date: Sat, 27-Jun-87 09:05:44 EDT
Article-I.D.: ihlpa.4445
Posted: Sat Jun 27 09:05:44 1987
Date-Received: Sun, 28-Jun-87 01:38:15 EDT
References: <8706260543.AA20346@cogsci.berkeley.edu>
Organization: AT&T Bell Laboratories - Naperville, Illinois
Lines: 58
Keywords: ID-handler

In article <8706260543.AA20346@cogsci.berkeley.edu>, bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes:
> It just hit home that task & window id's are not really guaranteed to be
> unique.  It's a longshot, but a task or window could disappear, and a new one
> be created in it's place.  There would be no totally safe way of determining
> if what is at that location is that same window/task you talked to last time.
> 
> 99999 out of every 100000 Amiga programs won't need it, but my latest creation
> could make use of a 100% unique task key.  Possibly a sequential long,
> incremented and checked for uniqueness (You never know when that
> 4,294,967,296th task will start up!!) (I believe in truly infinite systems)
> 
> As it is there is a safe enough way for my program to work without this,
> and I can also check things like the stack pointers etc.  But I'm fanatic about
> reliability, so this does not sit very well.

ID-handler was written based on these same fears.
It always returns a new number each time it is called (unless you wrap it
around after 10**16 accesses :-).  So a task can call it and get back a
number suitable for unique (long-term) task (or whatever) identification.

My application was to allocate pipe names for shell pipelines.  Suppose:

	1>  producer | filter_1 | filter_2 | . . . | filter_n

is desired.  Now you typically want to start all n+1 processes concurrently.
This allows for maximum utilization of the CPU.  We can implement it so:

	Run producer >pipe_1
	Run filter_1 <pipe_1 >pipe_2
	Run filter_2 <pipe_2 >pipe_3
		.
		.
		.
	Run filter_n-1 <pipe_n-1 >pipe_n
	filter_n <pipe_n

The last filter can be "Run" if the pipeline is to be a background job.

Basing the pipe names on Amiga processid's may not work.  Suppose
pipe names are generated by concatenating pipe_i with the shell's
processid.  This works until a shell (possibly a background job running
a script) produces such a pipeline and then goes away, and then another
shell appears in its same place (it must be Friday the 13th!).  If
this shell tries to produce a similar pipeline, there could be name
conflicts with the extant pipes from the previous shell.

I don't believe in using DateStamps to obtain uniqueness (e.g., combination
of an existing identifier + DateStamp) on the Amiga because the date is too
easily changed.  Imagine some process initiated in your Startup-Sequence
which *must* have a unique identifier, uses its processid + DateStamp
(not arithmetic +), and then the owner changes the date (because no
battery-backed clock).  It is possible that another process will now obtain
the same "unique" id using the DateStamp (though admittedly unlikely).

An approach like ID-handler seemed the safest to me, and requires little
extra effort.

			-Ed Puckett.