Start one thread with result as and output, the other with result as an input. I can build a simple interface that will pause on waiting for data, and the join code does no change. The same code can multiple of graph joins simultaneously.
If the join wants a step and data from the application, but data is sot ready, just pause the thread, let the output catch up, join does not care. Ort pause he thread on buffer full.
I think that is the next task, write the simple interface between two joins.
If one use the same lazy J interface, for both output and input, then then then two threads share the 'database', each instance maintaining their own cursors. make it standard, it only requires an extra test in the attachment but has no impact on the join.
The join simply maintains valid states for the two cursors in the loop. Any other process can initialize another cursor on a database and run join distinctly over the same data.
In fact, who needs threads. One of the current cursors can signal pause, the join lop will keep a stack of pending pairs, and pick the next pair in order. The join is like a pit boss, but the code is simple since we know a pause happens before any action is taken on the cursors. We can halt and pause cursor pairs at the top of the loop.
Chaining joins is what it is all about, the successive refinements of big data into a useful structure, making compact graphs to represent meaning. Extracting the core refinement thatm has a better meaning in the new context.
Chaining alos lets us run iutility graphs, for example when the data are bid,ask then the pit bos becomes a graph with methods to re-structure the queues, into graphs. This all works.
No comments:
Post a Comment