DelayScheduler cleanup & Bootstrap

I am doing a pass to cleanup the DelayScheduler hierarchy.

I'll be refactoring of the hierarchy to aid code understanding 

and eliminate redundant instance variables from the original code.

The target structure is.... 

DelayNullScheduler -- minimum interface to avoid errors in rest of system (6 empty methods)

|__DelayBasicScheduler -- fully working sans race protection (equivalent to Courageous scheduler)

      |__DelaySpinScheduler -- plus race protection

Can someone advise how/where the Bootstrap loads Delay and the DelaySchedulers?

where the invocation of Delay_class>>#initialize selects the delay scheduler.

I need to determine whether during transition the Bootstrap might need to temporarily hop to a different scheduler,

and how to provide the new structure in the Image for operational testing before switching.

cheers -ben

On Sun, Apr 15, 2018 at 3:19 PM, Ben Coman <[hidden email]> wrote:

I am doing a pass to cleanup the DelayScheduler hierarchy.

I'll be refactoring of the hierarchy to aid code understanding 

and eliminate redundant instance variables from the original code.

The target structure is.... 

DelayNullScheduler -- minimum interface to avoid errors in rest of system (6 empty methods)

|__DelayBasicScheduler -- fully working sans race protection (equivalent to Courageous scheduler)

      |__DelaySpinScheduler -- plus race protection

Can someone advise how/where the Bootstrap loads Delay and the DelaySchedulers?

Delay and Delay schedulers are atomically loaded during bootstrap (because they are part of the Kernel package so far).

So there should be nothing special to do there.

 

where the invocation of Delay_class>>#initialize selects the delay scheduler.

Once the image is created, the first method invoked is

PharoBootstrapInitialization >> initializeCommandLineHandlerAndErrorHandling

which is in the image. You can change it as you please :).

 

I need to determine whether during transition the Bootstrap might need to temporarily hop to a different scheduler,

and how to provide the new structure in the Image for operational testing before switching.

In the bootstrap there is no "switching". A new image is created from scratch with the code that you provide...

Initially the image has no delay scheduler process, so calling `Delay class initialize` will create it for you.

So as soon as you define 

Delay class >> initialize

"Delay initialize"

Scheduler ifNotNil: [ Scheduler stopTimerEventLoop ].

Scheduler := MyNewScheduler new.

Scheduler startTimerEventLoop. 

SessionManager default 

registerSystemClassNamed: self name 

atPriority: 20.

The bootstrap will take it into account.

And tests will be run with that configuration.

Maybe there is something else to it?

You want to do test the switching also? Because for this I would do it with normal smalltalk code... no bootstrap involved...

 

cheers -ben

--

Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - http://www.cnrs.fr Web: http://guillep.github.io Phone: +33 06 52 70 66 13

I had hoped it would be something simple like that.

Thanks for confirming.