[Discuss-gnuradio] socket puzzles

[Bob Vincent]

I've been looking at the single_thread_scheduler, trying to understand its 
behavior relative to sockets.
I put in the patch on file_descriptor_source to allow partial results to 
return.
I also sink on the transmitter to a named pipe, and source on the receiver 
on the same named pipe, to bypass the USRP.

When I telnet to my open source socket, I can type at it, and eventually my 
data comes out. The amount that comes out is a function of the number of 
sends I do, rather than
the number of bytes in the payload. (I set the payload really low for this 
purpose. I find that I need to source [payload + frame header + 4] bytes to 
stimulate the first send.

Also find that the first thing it sends is a lot bigger (like it's clearing 
its throat) than one frame's worth of samples.

Once it gets to the receive side, it decodes, but the correlator produces 
exactly one symbol per pass (rather than noutput items if possible), so 
after a short while all the buffers are exahusted by it, so the receive 
side does single byte reads.

Finally, if I close the telnet connection on the transmitter some stuff 
empties out of the tx buffers. If I close the tx app, more stuff empties 
out of the receive named pipe.

I don't understand why it works this way.

It might help if someone could explain the operation of the scheduler. In 
particular I don't understand why the upstream module blocks when it could 
be working because the next thing is not ready to take its output.