Scheduler

From an email dialogue btw Ben Goertzel and Will Pearson, Feb 2009

    The choice of
    scheduler is important, it is something we allow to vary in our
    current computer systems. I have a vision where the scheduler
    specializes to the tasks assigned to it.


I see that you could do this ... and you could create a Scheduler 
object within OpenCog doing this ... but, I'm not sure it's the best 
way to go.

My inclination instead is to design a Scheduler object that has the right
tweakable parameters, and let the system adapt these parameters based on its 
situation.  Initially some heuristic procedures for adapting these parameters 
could be supplied, but then the system could adapt these procedures as well...
 

    It also
    allows the system to modify itself to protect itself from
    (unintentional as well as intentional) Denial of Resources attacks
    from the programs it runs. This factor can be crucial in how useful a
    system is in the real world.

    This brings me to another philosophical difference I have with
    opencog, I assume all programs are potentially malicious or just full
    of errors that can cause DoR attacks. This I think is necessary when
    working with systems that are experimentally self-programmable. And
    experimental self-programmability is necessary for interesting
    self-programmability as far as I can see.


Well, we thought about this a lot when designing OpenCog.

And we decided that it made sense to defer these issues till a later stage 
rather than messing with them from the start.  It seems clear they *can* be 
dealt with, within the OpenCog infrastructure ... and also clear that this is 
not a practical priority right now.  The priority right now is getting more and 
more intelligent functionality!!

Of course, **ideally** the system should not allow any MindAgent to grind it to 
a halt ...

But at the current stage of development, this doesn't seem extremely important, 
because we can have careful control over which MA's go into a particular 
openCog deployment.

It seems there are two kinds of bad MA's to be worried about, in future...

1)
A MA that contains nasty code that uses C pointers inappropriately and screws 
with heap memory ... or does something else analogous...

I guess this is not the worst long-term issue, in that once we get around to 
making an OpenCog version that writes its own MA's, it won't be writing them in 
C++.  It will write them in Combo or LISP or some nice language that doesn't 
allow pointer errors....

2)
A MA that contains infinite or very long loops, thus doesn't cede processor as 
rapidly as a MA is expected to.

In the case of automatically learned MAs, one can imagine some sort of 
automated program analysis being used to ward off *many* instances of this.  
But I guess it wouldn't catch all of them.

One could also imagine a "watchdog" thread that somehow  monitored other 
threads, checking to see if some rogue MA is monopolizing that thread longer 
than it's supposed to, and killing the thread if so ... and then penalizing the 
MA somehow.

...

Another, related (and more urgent) issue is the system should allocate 
resources preferentially to those MA's that are more useful ... which will be 
done by the assignment of credit mechanism (which is not programmed yet but is 
described in the OCP wikibook).

But if a MindAgent wants to suck up resources and not do anything useful ... 
it's often going to take quite a while for the system's "assignment of credit" 
mechanisms to get around to realizing the MA is worthless and denying it the 
STICurrency and LTICurrency it needs to operate.

-- ben