🚀 go-pugleaf

In article <1992Dec14.173023.11208@erenj.com>, srfergu@rufus.erenj.com writes:
> In a network of mine, I'm repeatedly running a loop that sequences
> through time, interpolates a time slice, renders, then records to video.
> 
> After about 200 or so frames (time slices), the machine bogs down, and
> starts thrashing. The order of execution gets strange, things slow
> down severely, etc.
> 
> I assume I must have filled up available memory some how and I've started
> paging heavily.

Its possible that your machine is paging because 
the arena has become fragmented.  For example, a lattice
might be allocated on several pages (a uniform lattice consists of 7 chunks
of memory, 8 for perimeter and curvilinear).  

If your loop controller doesn't wait for a completion signal from
Render, then you could be filling memory with slices that are waiting
to be processed, and that could also cause paging.  You should loop a
'done' signal upstream to your controller.  Because of a bug,
this only works if you use a widget parameter.

As for the order of execution:  there is a problem with the firing
algorithm that you may be seeing if you are buffering a lot of data.
If the flow of data splits into two streams, then is joined into two 
ports of single module, and one stream is much faster than the other,
the data streams will get out of sync.  If you use upstream control to
regulate the flow, then this won't be as much of a problem. 

> 
> One of my modules creates a new lattice with cxLatNew, and returns a pointer
> to the lattice which goes to the module output port. I assumed that the
> Explorer executive would automatically free this lattice for me. Is that 
> incorrect? Should I be keeping this pointer as a global variable, and doing
> a cxDataFree on it before creating new lattices?

No, no, no.  Allocate a lattice using cxLat*New(), put it on the
output port with cxOutputDataSet(), and then you can forget about it.
The system will take care of manipulating the reference count to
reclaim the memory when downstream modules are done with it.  If you
wish to have data persist, increment its reference count with
cxDataRefInc().  When you are done, decrement the count with
cxDataRefDec().  You should never, ever use cxDataFree, as it may free
something that another module is using.  See the Module Writer's Guide, 
Appendix B.3 for more information.


Robert Skinner
robert@sgi.com

	We have read your manuscript with boundless delight.  If
	we were to publish your paper, it would be impossible for
	us to publish any work of lower standard.  And as it is
	unthinkable that in the next thousand years we shall see
	its equal, we are, to our regret, compelled to return your
	divine composition, and to beg you a thousand times to
	overlook our short sight and timidity.

			- rejection letter from a Chinese economic journal