[Top][All Lists]

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

Re: [Discuss-gnuradio] GNURadio scheduler behind the scene

From: Martin Braun
Subject: Re: [Discuss-gnuradio] GNURadio scheduler behind the scene
Date: Fri, 26 Dec 2014 21:47:00 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0

On 12/26/2014 04:27 AM, Philip Balister wrote:
> On 12/25/2014 07:38 PM, Joe D wrote:
>> Season's Greetings GNURadio community  and happy new year 2015!

I wonder which timezone you live in?

>> I was having a thorough read through  Tom Rondeau's  presentation covering
>> the gnuradio Scheduler Details, a big  thanks Tom for clarifying the
>> processes behind the scene,  is there a narrated/video version of this
>> preso?
>> I'm interested in knowing more about the scheduler, what are the
>> recommended literature/readings that cover the scheduler in more depth?
> The source. Please, we need more people that understand the guts.
> Philip


Please understand that this is *not* a lazy answer. If we actually wrote
a detailed description of the GNU Radio scheduler that's not simply the
source code, this would mean several man-weeks of core developer time
going into this project which could be spent elsewhere. The result would
be a document that's certainly longer than the actual source code, and
it would probably be out of date soon.

Oh, but a written document with lots of pictures would surely be easier
to understand, you might say? Well, first of all, that's highly
subjective. Maybe, if we had someone highly skilled in technical
writing, we might be able to make such a document. But again, it would
be absurdly expensive, with questionable return of investement.

Being a free software project, pointing people to the code is one of the
few luxuries we have. What could be a more concise explanation of the
source code than the code itself?

In fact, following the "Don't Repeat Yourself" principle, it would be a
bad idea to duplicate the structure in documentation. A high-level
description of the scheduler is something else, of course, but that's
why Tom made aforementioned presentation.

What if the code is badly written and hard to parse? Again, that's
subjective to a degree. But if something looks really badly written, or
could use an additional comment, there's always the mighty tool called
'pull request'.
We even fixed the spelling in one the scheduler's comments recently :)

On top of reading the code, I suggest asking specific questions here
(such as what does function x exactly do). This might encourage others
to read the code and also we'll have more info in the mailing list archives.


reply via email to

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