🚀 go-pugleaf

Hi,

	We are having a problem with the geometry viewer, it seems to be
missing certain inputs. I will explain the problem with the help of the
network below -


                                             +-----+
                                             |     |
			+--------------------+-+   |
			|         CM1          |   |
			| UI Module (Coroutine)|   |
			+------------------+---+   |
					   |    integer
					   |     (ack)
			                string     |
				      (file name)  |
					   |       |
			+------------------+---+   |
			|         SM1          |   |
			| Data Reader Module   |   |
			|    (Subroutine)      |   |
			+------------------+-+-+   |
					   | |     |
					   | +-----+
			                 field
					   |
			+------------------+---+
			|         SM2          |
			| Data Mapper Module   |
			|    (Subroutine)      |
			+------------------+---+
					   |
				        Geometry
					   |
			+------------------+---+
			|          G1          |
			|   Geoemtry Viewer    |
			+----------------------+


	CM1 (UI Module) implements a motif user interface, among various
ui components, there is a file selection dialog box, wherein a user can
select one or more files. If more than one file is selected, the module
will output the name of the first one and queue up the rest for subsequent
outputs. The file names in the queue are sent one by one to SM1 (Data Reader
Module), the module downstream. A name from the queue is output if and only
if an acknowledgement is received from SM1, which simply is an integer input
port in CM1. Finally when the queue is drained, CM1 will call
AVSmark_output_unchanged on its string output port, to prevent uncontrolled
loops.

	SM1 implements the file IO, it accepts a name from CM1 and reads
the file, creates an AVS field, and sets the first label to the filename.
After it is done it outputs the field to SM2 (Data Mapper Subroutine) and an
integer to CM1. The integer serves as an acknowledgement to CM1, which then
outputs another filename.

	SM2 implements a mapper which creates a geometry from the field.
The first label is extracted from the field and is used for the naming the
geometry. Hence each geometry object is named after the file from which the
data was read in. This geometry is output to G1 (Geometry Viewer).

	The above explains in a nutshell what we are doing. Now the problem
is that when a user selects multiple file names, for eg. A, B and C, only
the geometry corresponding to C shows up in G1. When looking at the printf's
to trace the flow of the data, we see that SM1 has successfully read all
the files, and SM2 has successfully generated the corresponding geometries.
So there is no loss of data among CM1, SM1 and SM2. However G1 is missing
the geometries corresponding to A and B. Isn't the flow executive supposed
to handle this?

	Now I know that in the interface between a coroutine module running
asynchronously and a subroutine module, data loss is possible. We took
elaborate measures to counter this by passing all the critical data through
FIFO buffers and having an acknowledgement mechanism to time the outputs
properly. This solution has worked very well for us.

	However I did not expect data loss between a subroutine module and
the geometry viewer (which is a builtin module). Is it possible that the
geometry viewer also runs asynchronously like a coroutine module? If so the
upstream information currently put out is inadequate. For instance in the
problem above upstream information about objects being added should be
sent out, so that the upstream module can know when it is safe to output yet
another geometry.

	Ofcourse the proper and elegant solution would be to use queues on
the geometry viewers input ports, as FIFO buffers, so that no data is lost.

	Now I will describe the current work-around we are using. In SM2
we call GEOMinit_edit_list only once and reuse the edit list for subsequent
invocations. This seems to solve the problem and all the geometries appear
without being lost. The code fragment looks like this,

		if( !*geom ) // Dangerous! remove this later
	    		*geom = GEOMinit_edit_list( *geom );

		GEOMedit_geometry( *geom, name, obj );
		GEOMdestroy_obj( obj );
	
however I am afraid this might be a very bad thing to do :^) What are the
possible repurcussions of reusing the edit list, without initializing it?
I guess the list will keep growing endlessly. Also deletions would become
a headache.

	I hope I am missing something very obvious, if so please point it out.
In either case any help, suggestions and or workarounds would be greatly
appreciated.

Thanks,
Srinivas
Landmark Graphics Corp.					(713) 560-1073
-- 
Yonder, beyond the event horizon!