[Discuss-gnuradio] Question about basic GSR internals

[David Beberman]

I'm currently looking through the 2.1 version of GSR.
I want to confirm that I understand what I'm looking at.
There is only one execution thread for a flow from source to sink(s).
(I assume it is possible to have multiple flows set up, and each one
would run in a different thread, but I don't have a use for that yet.)

I haven't looked through the flow graph sorting code, but I expect that
the idea is to go from sinks to sources, consuming buffers upstream
and putting the results in the downstream buffers for each block.  Thats
what makes sense to me.

In general, for asynchronous digital transmissions, there is usually some
sort of preamble that the receiver can lock on to, do some frequency, 
timing,
and phase recovery, and then send the rest of the received input on to 
other stages.
I would like to implement this within the GSR structures.

I was thinking of the following:
1: For each block that participates in preamble parameter recovery of 
some kind,
have that block be a terminating sink. 
2: Once such a block has completed its processing, the parameters are 
made available
through a global parameter block.  This could be protected with mutexes 
for future
multithreading operation.
3: Each of these blocks needs to stop receiving input after the required 
processing has completed
to avoid consuming CPU cycles.  I can see two possibilities.  The first 
is to have each block
return 0's on the forecast method.  This should stop the scheduler from 
calling the work routine.
There is still processing overhead from making the forecast method call.
The second approach would be to take the flow graph edge out of the 
graph completely. 
I have to look through the flow graph sorting code to see how much extra 
processing this
might entail.

4: At the end of processing an asynch frame, the system needs to be 
reset for the next frame.
If each block uses the forecast method to enable/disable scheduling, 
this is an out-of-band reset
to the blocks then.  For the second approach of changing the flowgraph, 
the same processing
issue exists.

I haven't looked into the gr_block_detail code yet.  May understand 
things better after reading that.

Please let me know if I'm somewhat on the right track.

Thanks,

David Beberman