[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] socket puzzles
From: |
Eric Blossom |
Subject: |
Re: [Discuss-gnuradio] socket puzzles |
Date: |
Fri, 25 Feb 2005 12:18:46 -0800 |
User-agent: |
Mutt/1.5.6i |
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