# GNURadio scheduler behind the scene

**URL:** <https://www.ruby-forum.com/t/gnuradio-scheduler-behind-the-scene/233586>\
**Category:** GNU Radio\
**Created:** [December 26, 2014, 1:40am UTC](https://www.ruby-forum.com/t/gnuradio-scheduler-behind-the-scene/233586 "2014-12-26T01:40:05Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\
**Post date:** [December 26, 2014, 1:40am UTC](https://www.ruby-forum.com/t/gnuradio-scheduler-behind-the-scene/233586/1 "2014-12-26T01:40:05Z")

</div>

Season’s Greetings GNURadio community and happy new year 2015!

I was having a thorough read through Tom R.'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?

Regards  
Joe

---

<div class="post-metadata">

**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\
**Post date:** [December 26, 2014, 4:28am UTC](https://www.ruby-forum.com/t/gnuradio-scheduler-behind-the-scene/233586/2 "2014-12-26T04:28:51Z")

</div>

On 12/25/2014 07:38 PM, Joe D wrote:

> Season’s Greetings GNURadio community and happy new year 2015!
> 
> I was having a thorough read through Tom R.'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

---

<div class="post-metadata">

**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\
**Post date:** [December 26, 2014, 10:09pm UTC](https://www.ruby-forum.com/t/gnuradio-scheduler-behind-the-scene/233586/3 "2014-12-26T22:09:47Z")

</div>

On 12/26/2014 03:47 PM, Martin B. wrote:

> 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?  
> I’ll augment what Martin said by observing that even in  
> long-established, _commercial_ code-bases, a  
> “structured walk-through” document that gives a re-expressed in plain  
> English and pictures overview is  
> actually, in practice, a bit of a rarity. In my 35+ years being  
> involved in software development,  
> I’ve only seen it on a few projects, and only on projects that had  
> reached a development  
> stagnation, where it was largely just in maint mode, which meant it  
> was perhaps reasonable  
> to invest in tech-writing resources to provide stable “internals”  
> documentation.

Nothing is preventing anyone from writing such a document, and  
contributing it. But since this is  
open-source, people largely work on what they _want_ to work on.  
There’s no paycheque  
(or threat of the lack of paycheque) hanging over peoples heads,  
forcing them to work on things  
they don’t really want to work on. And _most_ developers aren’t  
particularly-motivated tech-writers,  
and neither are they, for the most part, very good at it…

---

<div class="post-metadata">

**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\
**Post date:** [December 26, 2014, 9:48pm UTC](https://www.ruby-forum.com/t/gnuradio-scheduler-behind-the-scene/233586/4 "2014-12-26T21:48:09Z")

</div>

On 12/26/2014 04:27 AM, Philip B. 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?

> Philip  
> +1.

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.

Cheers,  
M
