On Fri, Feb 25, 2005 at 02:15:05PM -0500, Bob Vincent wrote: > 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.
FYI, if you're using the version in CVS, there's no patch required. It also handles the corner cases correctly. If you aren't, please build gnuradio-core from CVS so that I can be sure that we're talking apples-to-apples. > 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. The scheduler is pretty simple. The high level python code performs a one-time topological sort on the blocks. gr_single_threaded_scheduler just starts at the top of the list and for each block in turn tries to run it. A block can run if (1) there's enough input available in the upstream buffer and (2) there's room to put the output in the downstream buffer After running or not-running the block in question, it goes on to the next block in the list and so on. There are a few complications regarding propagation of the "done" flag (typically used to indicate EOF), but it's a corner case. The behavior you've described may be a result of meeting some block's output_multiple_requirement. Without seeing your code, I can't say. If you can come up with a small test case that demonstrates the problem I'll look at it. Eric _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
