[K42-discussion] Fun with dispatchers...

[Bryan S Rosenburg]

Nathan Sweet <nsweet at cs.unm.edu> wrote on 11/20/2005 01:35:39 PM:
> First, what is the status on the ability to use an alternate 
> dispatcher?  I know this topic has come up several times in the past, 
> but I was curious to know if anybody has been successful at doing this 
> and, if so, what's the process for accomplishing that task?

Nathan, I'm afraid the story in this area hasn't improved at all since my 
last couple postings on this subject.  I've pasted some text from those 
postings at the end of this note.  I think the best approach is still to 
link your application statically against your modified Dispatcher 
implementation.  We may still have issues with loading a statically-linked 
app, however, so when you get to that point let us know.

> Second, I'd like to have my dispatcher do something a little different 
> when creating threads, but it is, apparently, necessary to call the 
> scheduleFunction() methods in the Scheduler, which then makes a call to 
> the scheduleFunction() methods in the dispatcher.  What I want, for 
> example, is to have the thread management code (e.g., the SimpleThread 
> class) to make calls directly to the dispatcher to create threads, 
> instead of going through the Scheduler, so I wouldn't have to modify the 

> Scheduler class (my scheduleFunction() method takes a different set of 
> parameters).  What would be the best way to do this?  Declare my new 
> scheduleFunction() method as public instead of protected?  Declare 
> SimpleThread a friend class in the dispatcher?  Or something else?

We've deliberately isolated the dispatcher implementation class behind the 
Scheduler interface as a first step toward supporting alternative 
dispatcher implementations.  Your dispatcher implementation will have to 
support the Scheduler interface, because that's the interface the rest of 
the K42 library uses, but it can also define new public methods for 
specialized purposes.

- Bryan

-----------------------------------------------------------------------
Here's some text from earlier postings.

>From 11/18/2004:
-----------------------------------------------------------------------
The kernel has nothing to do with creating DispatcherDefault's or 
DispatcherNew's.  The kernel knows only about the base class, Dispatcher. 
How the base class is extended for a particular program is determined 
entirely by how the program is built and linked.

Unfortunately, substituting DispatcherNew for DispatcherDefault in a 
program isn't yet as easy as we'd like it to be.  I think you have to find 
and make copies of all source files that reference DispatcherDefault 
explicitly.  The copies should reference DispatcherNew instead of 
DispatcherDefault.  Then your program must be linked against the copies.

Our intent was to contain all references to a particular Dispatcher 
implementation in a single Scheduler.C file.  All the rest of the K42 
library would be programmed against the interface defined in Scheduler.H, 
which does not explicitly name any particular Dispatcher subclass.  We've 
managed to adhere pretty well to this model, I think, but there's a 
cluster of files that are entwined with DispatcherDefault 
(DispatcherMgr.C, SchedulerTimer.C, TimerEvent.C, etc.) that in some sense 
have to be considered part of the implementation of DispatcherDefault. And 
of course, DispatcherDefault.C, DispatcherDefaultExp.C, and 
DispatcherDefaultAsm.S are directly part of the implementation of 
DispatcherDefault and will have to be copied.  If you change the data 
layout of DispatcherDefault, you will have to define new assembler field 
offsets in genConstants.C and genConstantsArch.C.

I'm sorry it's not easier.  We still have work to do in this area.
-----------------------------------------------------------------------

>From 02/03/2005:
-----------------------------------------------------------------------
I never promised this would be easy!  :-)

Seriously, I'm sorry that it's not easier to experiment with alternate 
dispatcher implementations, but we're just not there yet.  You're 
exploring new territory.

I think you should aim at creating a statically-linked executable that 
contains your user program, your customized dispatcher implementation, and 
everything else from the K42 library.  A first step is to create a 
statically-linked executable that contains the standard dispatcher 
implementation.  I've been playing with that this morning, starting with 
hello.C in kitchsrc/usr.  I found that I could create a statically-linked 
hello by adding the following arguments to the link:

        -static \
        -L<your_install_dir>/lib/powerpc/fullDeb \
        -Wl,--whole-archive \
        -lemu \
        -Wl,--no-whole-archive \
        -Wl,-e,_k42start \
        <your_install_dir>/lib/powerpc/fullDeb/ProgExecUsr.o \
        -lbase \

You may have to adjust some of the other link arguments, but there's 
nothing too complicated.

With these arguments, your executable will be getting it's dispatcher 
implementation from libbase.a in <your_install_dir>/lib/powerpc/fullDeb. 
Any .o's that you place in front of the -lbase argument should override 
the standard versions in the archive.

There's one big fly in the ointment with this approach, however.  The K42 
program loader isn't currently capable of launching a statically-linked 
executable.  The loader needs to be fixed, and we're not going to be able 
to get to it for at least a couple weeks.  (We have a couple important 
deadlines in the next few weeks, so we're all quite busy.)  If you get 
your executable built and want to look into the loader problem, by all 
means let us know.
-----------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/k42-discussion/attachments/20051122/ebe7499c/attachment.htm