From: rasure@nell.eece.unm.edu (John Rasure)
Newsgroups: comp.soft-sys.khoros
Subject: (long) data transport, scheduling, real-time processing ......
Date: 6 Apr 92 19:33:17 GMT
Article-I.D.: pprg.37299


Hello Mr. Sadkin,

Danielle and Mark turned the discussion they were having with you over
to me since you are asking detailed questions about the architecture of
Khoros.  I hope I can give you concise answers to your questions with out
rambling.  I cc'ed this to the khoros mailing list since many of the
questions and answers may be of general interest.

John Rasure

} How can you collapse a group of programs into "procedures"? 
} (procedure to me means "function"; if you mean something else, please explain.)
	When a cantata network gets too big and unweildy, you can make a 
	group of glyphs into what we call a "visual procedure".  You 
	might call it a "subroutine" or "macro" -- the operation is 
	comparable to creating a subroutine in a segment of C code because the 
	code is getting too big and detailed.
	It is important to point out that the "visual procedure" is still
	executed as a set of processes.  The visual program is heirarchical
	in terms of variables and connections, the dynamic scheduler is
	recursively called to execute the hierarchy.

} 
} > 	"compiler" for cantata which would convert a visual program into
} > 	a shell script or C program.  
} 
} Bummer.  This is kind of necessary for, as we want to have cantata be "behind 
} the scenes" at execution of our process net, and essentially, we want a 
} "configure and forget" execution model.

	We do have plans to do a variation on this for Khoros 2.0;  our
	approach will be to "collapse" a visual program into a separate program,
	which I believe may be comparable to your "configure and forget" 
	execution model.   I have just finished a paper for Xhibition '92, which
	describes our plans for this (discussed at the end of the paper).  It 
	is available on pprg.eece.unm.edu for anonymous ftp from 
	pub/khoros/misc/papers/papers_xhibition/ui.ps.Z

} 
} I take it cantata does all the execing?  

	Yes.
} 
} > 
} > } 
} > } 2b) How do subsequent modules down the dataflow figure out when to "fire"?  
} > 
} > 	The default operation of cantata is to be data driven.  That is,
} > 	when a glyph's output changes, all glyphs "downstream" of the first
} > 	glyph are re-executed because their input has changed.  When you
} > 	turn on the "Responsive Execution" flag, the execution model is changed
} > 	from the data drive model to a hybrid demand driven model.  That is,
} > 	the flow graph will execute whenever a user modifies a connection or a
} > 	live parameter.  Re-execution occurs when the user clicks on a glyph's
} > 	RUN button, or if the user changes any live parameter in a pane. 
} 
} Ok: by execute, do you mean respawn the process?, Do you respawn the 
} downstream processes each time the data upstream changes?  See, this is 
} where I get confused about the filter/process distinction.  If you respawn 
} each time input arrives, and exit once you've finished processing the input, 
} then each "process" is essentially just a filter, and can be thought of as 
} a function run on the input.
} 
} If you do respawn via cantata every time data arrives on a node's input
} connections, then cantata *must run all the time* to manage this...
} which is bad for us, and thus my question 3).

Cantata serves several functions:  1) visual editor, 2) dynamic scheduler, and
3) distributed dispatcher.  Cantata has about as much overhead as a 
Unix shell in terms of execing processes.  Because cantata provides
language features such as data dependent flow control and loops, a
dynamic scheduler is needed to execute the "graph" regardless of whether or
not the visual editor is present.

As will come out in the discussion below, there are major differences between
executing "block" processes and "stream" processes.  And I think this is
where the confusion is coming from.  Visualization environments all
use "block" processing, process control and real-time processing require
at least some "stream" processing.  Khoros 1.0 patch 5 does have a mixed
mode stream and block processing capability hidden away in it, but we did
not expose it in cantata ..... waiting for Khoros 2.0.


} > 
} > } 
} > } 3) Can I set up a flow graph whose processes just establish communication 
} > }    paths, and then have each process "pend" on it's firing criteria, without 
} > }    relying on a central authority to execute?
} > 
} 
} ie. a "configure and forget" model.
} We need a "process" to be a semi-autonomous program, which has it's own
} GUI, and may sit dormant until it gets either other program input or
} user input, and then send messages other programs running in the system 
} which may only affect *how* the receiving programs process some other input,
} rather than just re-invoking the program.
} 
} These receiving processes would then "listen while running" for these incoming
} messages along the instantiated data paths, but continue to run and process
} their primary inputs.
} 
} 
} > 	You can always set up your own glyphs and fire when you desire, but 
} > 	this does require that you use a stream based transport rather than 
} > 	a block transport as the communication path.  Which is where cantata 
} > 	has it's current limitation.  Look at 5) for more details....
} ok...
} 
} [4) and response deleted, as it is more an implementation question which is
} answered if 3) is achievable...]


If you execute a stream based process in cantata .... it starts and keeps
on processing data as it arrives.  If you execute a block based process
in canatata .... it has several run modes; start, process, stop; start,
start another; start; continue and read new data blocks as available.

} 
} > } 
} > } 5) Can you set up a graph which is "event driven", ie. the 1st module in the
} > }    dataflow pends on a device, but "fires" as soon as the device generates
} > }    input (a signal)?
} > 
} > 	This is how cantata will schedule glyphs that use the data services or
} > 	data transport.  For processes that don't use either cantata will
} > 	schedule descendants when the process terminates.  The way this works
} > 	is that a special transport is setup that the exec'ed processes are
} > 	obligated to communicate thru when a process uses our data transport
} > 	(this is all hidden from the programmer and the user).  What happens is
} > 	that every time an input is opened and closed the process negotiates
} > 	that transaction.  In this way cantata can keep track of the processes
} > 	and can re-schedule glyphs to make sure that stream based transports
} > 	will have both a consumer and producer.  It also allows us to schedule
} > 	processes that maybe devices (as you mentioned above).  A simplier
} 
} So your wrapper builder (composer?)  adds code which performs these
} operations on each transaction, so that cantata can then "fire" (re-exec?) the 
} connected glyphs?  
} 
} > 	example is to hook the output of editimage (which is the ROI or OUTPUT
} > 	imageout).  Currently when running this network the user selects a
} > 	region of interest which is outputed to the rest of network, but the
} > 	network won't continue until editimage is exited.  With the new method,
} > 	everytime the region is outputted the rest of the network is immediately
} > 	scheduled/fired.  The other benefit is that processes where a data 
} > 	transport has not been explicitly defined can then negotiate the 
} > 	transport they wish to use.  Hopefully this would mean that stream 
} 
} ???  new method vs old? (don't understand which methods the adjectives refer
} to... ) (aside: this doesn't fit into my (probably mistaken) current view of
} respawned glyphs; how does the data recipient become aware of the new
} transport connection if it isn't continously running?)

Khoros has many, many layers.  The basic philosophy is to make the most
appropriate layer responsible for its decisions.  In this case, cantata
is not concerned with two processes communicating, once that cantata
has started them .... the data transport layer is responsible.  The data
transport can signal cantata when it needs to, but it will leave two
processes alone that are producing and consuming a stream.

} 
} > 	based processes would end up negotiating stream based transports 
} > 	automatically and block based processes that take a long time to 
} > 	execute would end using a permanent block based transport like file,
} > 	shm,etc.  And finally, we are looking at using the same negotiator 
} > 	technique for doing parallel processing.  I realize that this
} > 	is more than you were asking for, but i feel that this information may
} > 	help you understand how your applications may fit into the Khoros
} > 	environment. 
} (aside: if you have a central negotiator, it will be a bottleneck...)

Nope, the "central negotiator" only makes a decision when it has to.  Data
is not routed through cantata.

} 
} > 
} > 	The unfortunate thing is that i wouldn't expect to see any of this until
} > 	Khoros 2.0.  I do have an initial version that does some of this now, 
} > 	but it still has a lot of kinks to work out.  The example that i have 
} > 	working starts a process and then the output of that process will re-
} > 	schedule all descendants each time data becomes available, which is 
} > 	what i think your question is about.  Also, if a descendant wakes up 
} > 	and demands data then its parents will be re-scheduled (which is what 
} >         i think you were asking in question 4).  As for question 3) if a 
} >         stream or socket was used as the communication then i would expect 
} >         that whether the glyph re-fired or not should really not affect 
} > 	cantata, but i would need more details before i could say for sure.
} 
} Actually, 4) referred to more of a network of processes which was basically
} feed-forward, but included negotiated transaction of data between 
} subcomponents of the processing, which doesn't so much "re-schedule" the
} parents (they aren't really parents, more like siblings) as change the
} behavior of the parent.
} 
} As for 2.0, any guess as to when this will be coming out?

Khoros 2.0 is scheduled for a year from now, maybe longer.  
Our plans for 2.0 are "somewhat ambitious"...

Consortium members will be getting earlier releases.

=============================================================================

The conversation continues .......


} Danielle,
} 
} I have been reading more of the user's manual, and still have the impression
} that the glyphs of a cantata program can be thought of as filters,
} and as such, get spawned each time new data arrives for them, and all this
} is controlled by the cantata program.  Also, I get the impression that
} intermediate files are generated, so that the command line interface works...

Intermediate files are one of the available transports.  Transports are
either persistent (file, shared memory, SVM) or non-persistent (socket, pipe,
stream).

} 
} I also have a more concrete example of what we need to do, and maybe this
} will help you answer my concerns:
} 
} Mark Young's animate program is more like our program subcomponents, in that
} it has a user interface, and basically runs as a standalone program.  
} 
} Now, rather than using the user interface, suppose you had another
} separate program whose responsibility it was to generate colormaps via
} some algorithm on its own inputs, and feed this to the running animate
} program, so that it could change colormaps as it ran.

This is doable ... try it with editimage with update mode active.

} 
} Say you had another program which managed its own display, but also 
} wished to coordinate its own display speed and the animation speed of
} the running animate program.  
} 
} In a more interactive and complicated mode, say you had a couple of programs 
} which generated animation data, and you wanted to toggle between animation 
} sets without starting up a new copy of the animate module.
} 
} These are typical of the kind of operation our application needs to do 
} between its subcomponents.  

putimage and editimage can run this way now.

} 
} However, we don't want to have to write each subcomponent to have specific
} knowledge about what it's connected to; the colormap module would just 
} output colormaps; the animate module would just listen for colormap changes.
} We want the initial connections between the pieces to be set up by
} some external coordinator (something like flow-graphing in cantata), and
} then not have to "schedule" anything, but just let each component keep
} running.

That is what cantata does.  Once editimage is started from cantata in
update mode, it is editimage's responsibility to sense changes and update.

} 
} We are considering writing our own "script language" which extends the
} notion of pipes between processes to include message pipes (sockets),
} data pipes (shared memory), and a couple of others that elude my brain
} at the moment, and which allows multiple connections into and out of
} programs; these scripts would then be run through an interpreter which
} would negotiate and establish the connections between the programs, and
} then die.  The programs would then monitor their own inputs and manage
} their own firing criteria.

Mark Young is finishing a paper on the data transport, data services and
parallel heterogeneous libraries we are building for Khoros 2.0.  It 
explains how we are implementing the above.

} 
} My last problem statement would be a reason to have the "flow-graph manager" 
} hang around, so that it could re-negotiate the connections.  Your
} previous reply led me to believe that your work was heading in this
} direction.

yes.

} 
} We were hoping that cantata, if not immediately capable of all of this, 
} might be easily modifiable to do so.  

us too.

} 
} Anyway, I look forward to hearing from you, and hope we can come up with
} some way of not having to reinvent the wheel...
} 

Maybe we can improve the wheel together.

} 
} --Will
} -------------------------------------------------------------------------------
} Will Sadkin                 |"Never draw what you can copy;
} Internet: wsadkin@bbn.com   | never copy what you can trace;
} BBN Systems & Technologies  | never trace what you can cut out and paste down!"
} -------------------------------------------------------------------------------
} 


John Rasure, Danielle Argiro, and Mark Young