[Seaside-dev] question on value of startup and shutdown lists
being required
Philippe Marschall
philippe.marschall at gmail.com
Sun Mar 23 09:25:55 UTC 2008
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
More information about the seaside-dev
mailing list