[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
Re: [Discuss-gnuradio] CPU usage when hdlc framer is used,
Andy Walls <=