Playing with a declarative startup/shutdown subscription mechanism
Locked
Playing with a declarative startup/shutdown subscription mechanism
 
|
Hi!
Last days I was playing to replace the image startup/shutdown mechanism via a pragma subscription because I was pissed off with how difficult is to integrate the change of a new startup in the system. The idea is:
- reduce the mess on subscription/unsubscription, initialization, etc - reduce dependencies of external packages in core packages. This way, if you want to subscribe a class side method to be executed on startup, you annotate it:
SomeClass>>startUp: resuming <systemStartup: #application> self blahblah.
SomeClass>>startUp: quitting <systemShutdown: #kernel> self blahblah.
Now, instead of an order in classes startup, I played with the idea of having run levels (which I named #kernel, #application and #user because I was not inspired :P). Then I replaced the whole system startup and It's working...
The code is very simple, you can have a look at the category System-Tasks which can be downloaded from: MCGemstoneRepository location: 'http://ss3.gemstone.com/ss/PharoTaskForces'
user: '' password: '' SLICE-Issue-666-Playing-With-startup-GuillermoPolito.2
Be careful, that package contains the startup code + the replacement of the old startup by the new one :). Now, I'd like to have some feedback, u like it? u buy it? which should be the names for the run levels? how many run levels should we have? :P
Cheers, Guille
|
Re: Playing with a declarative startup/shutdown subscription mechanism
|
|
I have the impression that you will need a finer order at least for the kernel.
so putting > SomeClass>>startUp: quitting > <systemShutdown: #kernel priority: 1000> > self blahblah. looks to me the way to go and yes we should clean that part two. Now what is the gain to have pragma and not just a class side method returning a number? Stef > Hi! > > Last days I was playing to replace the image startup/shutdown mechanism via a pragma subscription because I was pissed off with how difficult is to integrate the change of a new startup in the system. The idea is: > - reduce the mess on subscription/unsubscription, initialization, etc > - reduce dependencies of external packages in core packages. > > This way, if you want to subscribe a class side method to be executed on startup, you annotate it: > > SomeClass>>startUp: resuming > <systemStartup: #application> > self blahblah. > > SomeClass>>startUp: quitting > <systemShutdown: #kernel> > self blahblah. > > > Now, instead of an order in classes startup, I played with the idea of having run levels (which I named #kernel, #application and #user because I was not inspired :P). Then I replaced the whole system startup and It's working... > > The code is very simple, you can have a look at the category System-Tasks which can be downloaded from: > > MCGemstoneRepository > location: 'http://ss3.gemstone.com/ss/PharoTaskForces' > user: '' > password: '' > > SLICE-Issue-666-Playing-With-startup-GuillermoPolito.2 > > > Be careful, that package contains the startup code + the replacement of the old startup by the new one :). > > Now, I'd like to have some feedback, u like it? u buy it? which should be the names for the run levels? how many run levels should we have? :P > > Cheers, > Guille |
Re: Playing with a declarative startup/shutdown subscription mechanism
|
|
On 5 August 2012 23:37, Stéphane Ducasse <[hidden email]> wrote:
> I have the impression that you will need a finer order at least for the kernel. > so putting >> SomeClass>>startUp: quitting >> <systemShutdown: #kernel priority: 1000> >> self blahblah. > > looks to me the way to go and yes we should clean that part two. > > Now what is the gain to have pragma and not just a class side method returning a number? > > Stef > subscription (you have to scan over all methods with such pragma). i cannot remember what solution i proposed.. ah ok.. i recall. i proposed to introduce a session-awareness. i.e. an object holds a reference to a session object and before each access to its some session-specific resource it should check if session has changed or not. and if session is obsolete, then you know that you must reinitialize (meaning do a startup). this is what i did in NB: it does not registering for startup, but instead it initializing at first attempt to use it. So if nobody using it, nothing happens (means no extra cycles burned at startup for nothing). This also solves nicely a problem with priority of service initialization: - imagine service A requires service B to function, but user code attempts to access a service A first. Now since service A will try to access a service B first, as result, a service B will be naturally (re)initialized first. Like that, you don't even need to think (or make sure), who should be (re)initialized first, because chain of priority automatically adjusts itself according to program flow. -- Best regards, Igor Stasenko. |
Re: Playing with a declarative startup/shutdown subscription mechanism
|
|
On Aug 5, 2012, at 11:57 PM, Igor Stasenko wrote: > On 5 August 2012 23:37, Stéphane Ducasse <[hidden email]> wrote: >> I have the impression that you will need a finer order at least for the kernel. >> so putting >>> SomeClass>>startUp: quitting >>> <systemShutdown: #kernel priority: 1000> >>> self blahblah. >> >> looks to me the way to go and yes we should clean that part two. >> >> Now what is the gain to have pragma and not just a class side method returning a number? >> >> Stef >> > the downside of it, that you apparently more slower than explicit > subscription (you have to scan > over all methods with such pragma). yes this is why I propose sending a message but may be you have to send a message to all classes so this is bad too. > > i cannot remember what solution i proposed.. ah ok.. i recall. > i proposed to introduce a session-awareness. i.e. an object holds a > reference to a session object > and before each access to its some session-specific resource it should > check if session has changed or not. > and if session is obsolete, then you know that you must reinitialize > (meaning do a startup). > this is what i did in NB: it does not registering for startup, but > instead it initializing at first attempt to use it. So if nobody using > it, nothing happens (means no extra cycles burned at startup for > nothing). > This also solves nicely a problem with priority of service initialization: > - imagine service A requires service B to function, > but user code attempts to access a service A first. Now since service > A will try to access a service B first, > as result, a service B will be naturally (re)initialized first. > Like that, you don't even need to think (or make sure), who should be > (re)initialized first, because chain of priority automatically adjusts > itself according to program flow. Yes this is more modular. > > -- > Best regards, > Igor Stasenko. > |
Re: Playing with a declarative startup/shutdown subscription mechanism
|
|
In reply to this post by Igor Stasenko
On Sun, Aug 5, 2012 at 2:57 PM, Igor Stasenko <[hidden email]> wrote:
No. Registration can be done when methods are added or removed. Pragmas don't have to be scanned on each invocation. Instead the need is for a hook when methods are added or removed, and such hooks exist.
best, Eliot |
Re: Playing with a declarative startup/shutdown subscription mechanism
|
|
In reply to this post by Guillermo Polito
On Sun, Aug 5, 2012 at 2:15 PM, Guillermo Polito <[hidden email]> wrote: Hi! You need before: and after:. IMO, you also need to support multiple befores or afters. I think that's much better than a priority scheme.
Also, as I said in response to Igor's message, you can register when pragma methds are added/removed, rather than looking for methods when initialization/shutdown is run.
best, Eliot |
Re: Playing with a declarative startup/shutdown subscription mechanism
|
|
On 6 August 2012 21:09, Eliot Miranda <[hidden email]> wrote:
> > > On Sun, Aug 5, 2012 at 2:15 PM, Guillermo Polito <[hidden email]> > wrote: >> >> Hi! >> >> Last days I was playing to replace the image startup/shutdown mechanism >> via a pragma subscription because I was pissed off with how difficult is to >> integrate the change of a new startup in the system. The idea is: >> - reduce the mess on subscription/unsubscription, initialization, etc >> - reduce dependencies of external packages in core packages. >> >> This way, if you want to subscribe a class side method to be executed on >> startup, you annotate it: >> >> SomeClass>>startUp: resuming >> <systemStartup: #application> >> self blahblah. >> >> SomeClass>>startUp: quitting >> <systemShutdown: #kernel> >> self blahblah. > > > > > You need before: and after:. IMO, you also need to support multiple befores > or afters. I think that's much better than a priority scheme. You also need a tool to visualise the resulting DAG, if you want to understand the order in which the resulting methods will execute. Dumping the pragmas in an appropriate manner in a dotfile would be ample. frank > Also, as I said in response to Igor's message, you can register when pragma > methds are added/removed, rather than looking for methods when > initialization/shutdown is run. > >> >> >> Now, instead of an order in classes startup, I played with the idea of >> having run levels (which I named #kernel, #application and #user because I >> was not inspired :P). Then I replaced the whole system startup and It's >> working... >> >> The code is very simple, you can have a look at the category System-Tasks >> which can be downloaded from: >> >> MCGemstoneRepository >> location: 'http://ss3.gemstone.com/ss/PharoTaskForces' >> user: '' >> password: '' >> >> SLICE-Issue-666-Playing-With-startup-GuillermoPolito.2 >> >> >> Be careful, that package contains the startup code + the replacement of >> the old startup by the new one :). >> >> Now, I'd like to have some feedback, u like it? u buy it? which should be >> the names for the run levels? how many run levels should we have? :P >> >> Cheers, >> Guille > > > > > -- > best, > Eliot > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |