[Seaside-dev] question on value of startup and shutdown lists being required

[Dale Henrichs]

Philippe Marschall wrote:
> 2008/3/23, Dale Henrichs <dale.henrichs at gemstone.com>:
>   
>> In Seaside2.9 system startup and shutdown lists are "required." I am
>>  wondering how necessary these lists are. It is easy enough to implement
>>  the startup and shutdown list, but I question their overall value. Doing
>>  things at startup is problematic because most of the useful things that
>>  are done at startup in other Smalltalks usually involve reseting a class
>>  variable or other global (as in the WAExternalId) which _will_ lead to
>>  commit conflicts in GemStone.
>>
>>  Fortunately, only WAExternalId uses the system startup list. The
>>  shutdown list appears to be unused.
>>
>>  In GemStone we have a technique for refreshing things when a new session
>>  is started without creating commit conflicts and without sending
>>  messages at vm startup.
>>
>>  I would think that using startup/shutdown lists is more of a
>>  platform-related technique used to solve specific problems as opposed to
>>  being an important part of the overall framework.
>>
>>  In the specific case of WAExternalId, we need a fresh Random number
>>  generator for each vm, but there are several ways to accomplish that ...
>>
>>    1. get the generator instance from SeasidePlatformSupport - causes
>>       bloat, but is offset by eliminating platform startup/shutdown.
>>    2.
>>
>>       have WaExternalId use a variety of Random (implemented as a
>>       Platform specific class) that refreshes its seed on system
>>       startup. In the non-GemStone case, the implementation would
>>       forwarding messages to a global where an instance of Random is
>>       stored. The instance is refreshed on startup....
>>
>>    3.
>>
>>       leave the startup method alone, but make it's use a platform
>>       dependent, i.e., on non-GemStone platforms WAExternalId would
>>       register for startup messages directly in a platform-specific
>>       message (#registerForStartup). #registerForStartup would be a noop
>>       in GemStone.
>>
>>  I assume that there are other possibilities.
>>
>>  At the moment I lean towards option 3.
>>
>>  Let me know what you think and I'll code it up ...
>>     
>
> One thing to keep in mind is package loading and package
> initialzation. Right now is looks like this:
> - provide Continuation
> - provide SeasidePlatformSupport
> - "normally" load Seaside-Core where "normally" means at the end
> happends class initialization
>
> The way I interpret 3 between loading the code and #initalize-ing the
> classes some other code has to be loaded in this case WAExternalId
> class >> #registerForStartup.
>
> Cheers
> Philippe
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>   
Okay,

Take a look at Seaside-Core-dkh.81, Seaside-Squeak-Core-dkh.33, 
Seaside-Tests-dkh.69 and let me know what you think...I've used lazy 
initialization of the Generator class variable to address the load order 
problem....

Dale