[Top][All Lists]

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

Re: [Discuss-gnuradio] [GREP] Separate scheduler and GNU Radio base file

From: Andrej Rode
Subject: Re: [Discuss-gnuradio] [GREP] Separate scheduler and GNU Radio base files
Date: Wed, 9 Jan 2019 17:36:31 +0100

Hi Martin, 

On Thu, 27 Dec 2018 13:54:54 -0800
Martin Braun <address@hidden> wrote:

> Hi all,
> final GREP of the day:
> https://github.com/gnuradio/greps/blob/master/grep-0016-separate-scheduler.md
> This is possible the most fundamental and influential GREPs that were
> added so far. I would find it hard to find any reasons not to do this
> -- of course, the question remains, who will do it. Any takers? I'm
> hoping that by separating scheduler from base, we can open up the
> avenue for more and better research into scheduling, as well as
> custom scheduler development.

So current situation is: we basically have a architecture where one
could write another scheduler and plug it into the current system. The
major problem with that: the current architecture has gone through a
lot of patching and growing and thus a lot of boundaries between blocks
and the scheduler have become unclear. 

Aside from uncluttering the runtime and cleaning up, a new architecture
design should be discussed without mental barriers looking at the
current design. Important points: how to we want to run the flowgraphs,
what owns the buffers, how are buffers handled, what schedules
execution of blocks, how is control communication done, how will
heterogeneous processing be handled (locally & distributed). 

This will change almost all interfaces of the current architecture and
thus I think the current scope of the GREP is still too narrow. 
I don't have a perfect solution for this. But fundamentally there is
need for more change than outlined. E.g. the word top_block & PMT
shouldn't be in there. Though I agree on the most basic point outlined:
the current UX must be preserved (or even improved).

I have some ideas on architecture and buffer handling in a new design,
but they need more thoughts & proof-of-concepts until they're ripe for

Thanks for starting the discussion!


reply via email to

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