DelayScheduler cleanup & Bootstrap

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

DelayScheduler cleanup & Bootstrap

Ben Coman
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
Reply | Threaded
Open this post in threaded view
|

Re: DelayScheduler cleanup & Bootstrap

Stephane Ducasse-3
Thanks Ben this is great to see this happening.
Thanks again. Now about your question:
I do not know and we should document it better, but everything in the
in github bootstrap + the scripts
Guillermo is teaching somewhere in France coming friday like me.



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?
> 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

Reply | Threaded
Open this post in threaded view
|

Re: DelayScheduler cleanup & Bootstrap

Guillermo Polito
In reply to this post by Ben Coman


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

Reply | Threaded
Open this post in threaded view
|

Re: DelayScheduler cleanup & Bootstrap

Ben Coman


On 19 April 2018 at 15:38, Guillermo Polito <[hidden email]> wrote:


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.

I had hoped it would be something simple like that.
Thanks for confirming.

 
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


Reply | Threaded
Open this post in threaded view
|

Re: DelayScheduler cleanup & Bootstrap

Stephane Ducasse-3
I had hoped it would be something simple like that.
Thanks for confirming.


This is power of having a working bootstrap!
Thanks Ben for helping improving Pharo.