[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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]