discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] CPU usage when hdlc framer is used


From: Andy Walls
Subject: Re: [Discuss-gnuradio] CPU usage when hdlc framer is used
Date: Thu, 18 Jun 2015 10:41:28 -0400

On Wed, 2015-06-17 at 12:01 -0400, address@hidden
wrote:

> Message: 11
> Date: Tue, 16 Jun 2015 16:04:54 -0700
> From: Johnathan Corgan <address@hidden>
> To: Marcus M?ller <address@hidden>
> Cc: "address@hidden" <address@hidden>
> Subject: Re: [Discuss-gnuradio] CPU usage when hdlc framer is used
> Message-ID:
>       <address@hidden>
> Content-Type: text/plain; charset="utf-8"
> 
> On Tue, Jun 16, 2015 at 1:32 PM, Marcus M?ller <address@hidden>
> wrote:
> 
> 
> > if I understand you correctly, you think the situation calls for
> > something like a "wait for message flag" that a block would need to set
> > every work call?
> 
> 
> Actually, this is the idea--that, *when needed*, make a call to the
> scheduler just before ending work, that says, in in effect--don't call me
> again until input message port X is not empty.
> 
> Otherwise, call me again whenever you otherwise would, which, for a source
> block, is when there is room in the output buffer (subject to other
> constraints.)
> 
> This would allow work() to be invoked one more times as needed, to exhaust
> any pending data that might exceed noutput_items in a given call, yet then
> finally wait on a message for more content.
> 
> The key point would be to not block in work, which prevents the scheduler
> from that block from processing any other events, but instead allow the
> scheduler itself to do so.

Hi John,

Yes, that seems right.

The block needs to continually keep the gnuradio infrastructure informed
about when to wait for a message or not, before calling work().  The
infrastructure can't possibly know otherwise.

Regards,
Andy




reply via email to

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