From: John Morrison (jmorrison_at_ahc.net.au)
Date: 2002-04-03 05:44:44
> ><<<< This was written today before Jim Posted his reply but I
> didn't want to
> >wast all that typing >>>>
> ><<<< Wrote this on my 2 hours train travel to work.......
>
> 2 hours?! Wow... that is one long commute.
Sorry I meant an hour each way........ :-(
> > The original “1 thread” proposed has the major disadvantage
> that if any
> >component gets into an endless loop or in some way locks up whole program
> >stops. So I think we should have a thread for the user
> interaction so that
> >if something does lockup at least the user can click “Exit”. Also there
> >WILL be ”User interface” modules that require constant updates even when
> >there is no real data. Eg MP3 player, animations, Setting up and closing
> >down the network.
>
> I know that Jim-P mentioned that the first conception of a node-network
was
> assuming one thread, but, I think, he meant this relative only for the
network
> -- not for the application as a whole. Thus, the Device would have its
own
> thread, other UI components will have theirs, and so forth, as you mention
above.
OK that puts a different complexion on things. :-)
> > ModuleA.outputNode(referance to Node1)
> > ModuleB.outputNode(referance to Node2)
> > ModuleC.outputNode(referance to Node3)
> >
> > ModuleB.addInputNode(referance to Node1)
> > ModuleC.addInputNode(referance to Node1)
> > ModuleC.addInputNode(referance to Node2)
> >
> > Operation by networkMain object(for above network)
> > // Check if new data exists
> > If Node1.newData()
> > Node1.resetDataFlag() (Is set when new data written)
> > ModuleA.process()
> > ModuleB.process()
> > ModuleC.process()
> > (Must be done after ModuleB has finished)
>
> I'm not sure what object is reading data from the Device in your example
above.
I'll clarify it. :-) SORRY!!!
OK think of this as ONLY the processor stage.
In this case I should have added a Node0 being the connection to the
previous stage.
Hows this?
Node0 --> ModuleA -> Node1 --> ModuleB --> Node2---> ModuleC -> Node3
\-----(Node 1 to ModuleC)----/
Operation by networkMain object(for above network)
// Check if new data exists for processor stage
If Node0.newData()
Node0.resetDataFlag() (Is set when new data written to node)
ModuleA.process()
ModuleB.process()
ModuleC.process()
> Perhaps ModuleA? If I am understanding the above correctly, then we
still run
> into the problem of having dependant processing nodes which might take too
long
> before we got back to the next read() on the Device.
Devices are in the previous stage with their own thread and Node0 handles
the buffering and any partial delays.
Of course if the processing takes longer to process then the data than for
ti to arrive will well have to loose data or speed it all up.
> Meaning that ModuleC could not be called until ModuleB was done, and
ModuleB could not
> be called until ModuleA was done, and so forth.
YEP!!
> Once Node1.newData senses waiting data from the Device (ModuleA?), then it
will start processing the
> node tree and, when finished with the last Module, finally get back to
reading from the
> Device.
Yep sorry I should have put in Node0.......... :-(
> Or do you see the Device being in its own separate thread, and feeding
data
> into the node network in some other way? Since you mention that each Node
has
> it's own data stream, then I am thinking that you are envisioning the
Device
> thread and the node-complex thread connected by a buffered stream?
Each node IS a buffer the previous Module places data into it's buffer and
the next Module take data from the Node.
When you register an output node (method outputNode()) the node ask the
module how big a buffer it requires and adjusts accordingly always taking
the buffer to the biggest asked for if there are more than 1 output modules.
This is the only time that a Node calls a Module ALL other times the
Module(s) call the node.
> Dave.
John
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:43 BST