On 9 October 2012 14:28, drush66 <[email protected]> wrote:
> Igor Stasenko wrote
>> 1. during startup, you have to be very careful about dependencies
>> between services,
>> the errors like using uninitialized service(s) makes image
>> unrecoverable (because VM crashing).
>> For example , putting 'Transcript show: ' before freetype initialized
>> may kill an image,
>> beyond the point of recovery. The hardest part in it, that since
>> everything is late bound, it sometimes really hard to put
>> initialization in right order. And loading any new code in image will
>> also contribute to chaos
>> of interdependencies, unless all developers know that they should not
>> use facility A before facility B is properly initialized. And the only
>> way to do it is to add own checks and one more #startup method,
>> which 'enabling' your service after all dependencies initialized.
>> But the problem is that the longer chain of initialization gets, the
>> more chances that something will go wrong (as well as getting lost in
>> order of dependencies).
>
> Just shooting from the hip, isn't that the same problem that more or less
> all unix os-es have on start up, what parts of systems are alive at
> particular moment and which ones are not. Instead of hard wiring all
> dependencies, maybe introduce different run levels, and roughly divide
> registered start up actions based on the run level?
>
>
run levels just adding another dimension into dependency soup.
they don't solve the dependency problem..
when you say "i run at level 5, so everything which runs at level 4
will be initialized first"
which is equal to saying " Facility A (level 5) should not be used
before facility B (level 4) is
initialized.

>
>
> -----
> http://www.cloud208.com/
> --
> View this message in context: 
> http://forum.world.st/Global-session-object-tp4650371p4650576.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>



-- 
Best regards,
Igor Stasenko.

Reply via email to