Actions performed at Program Startup

Contents

• Introduction
• VM Startup
• Class Initialization
• Smalltalk Startup
  • Clean Startup
  • Startup with an Image
• Actions Performed by the Script Files
• Installation of Autoloaded Classes
• Shortcut Start with an Image

Introduction

VM Startup

• allocate or mmap some memory for object space.
  On systems which provide a working mmap (or equivalent), the objectMemory is allocated by virtual allocation (i.e. mmap on '/dev/zero' under unix, or VirtualAlloc under MS-Windows).
  Systems with a half-hearted mmap-implementation (i.e. hpux), a temporary file is created, and the objectMemory is mapped onto that one.
  On all other systems, objectMemory is allocated via 'malloc()' - this has the disadvantage, that later resizing of the objectMemory is a much more expensive (i.e. slower) operation.

• load common symbols from the 'symbols.stc'-file
  (only done on some systems)

• read 'modules.stx' and load all DLL's as listed there
  (currently, only done on MSWindows systems; on all other systems, the list of built-in classLibraries is hard-wired into the stx executable. This 'hard-wiring' was done when the stx-executable was linked.)

• register all classes as present in the built-in classLibraries
  (this cares for the proper initialization order, and checks for the presence of a classes corresponding superclasses)

• create and register all global variables, as defined by all class libraries.

• create and register class-objects and all methods, blocks and global variables as contained in the built-in classLibraries.

• invoke all class-initialize methods (see below)

• perform further initialization (controlled by smalltalk-code, as described below)

• .
• ./include
• $SMALLTALK_LIBDIR/include
• $STX_LIBDIR/include
• /usr/local/lib/smalltalk/include
• /usr/lib/smalltalk/include
• /opt/smalltalk/include

• .
• .\include
• $SMALLTALK_LIBDIR\include
• $STX_LIBDIR\include

Class Initialization

Since traditional smalltalks always use an image, this will contain the initialized classes with all of their class variables and class instance variables (if any).

In Smalltalk/X no snapshot image is required: it can be started both with and without a snapshot. If started with a snapshot, the behavior is as described above: all objects are read from the image and the classes found there have already executed their #initialize method in the previous live.

If started without an image, all classes' #initialize methods are called at early startup time, sorted by class inheritance. These methods are responsible to create and setup any local objects required for proper operation of the class.
Inside a subclass inheritance level, the order by which those methods are invoked is not defined (i.e. in a classes #initialize method, you may depend on all superclasses being already initialized, but you may NOT depend on any other classes being initialized.

This means:

• always write your "class initialize" methods in a way that all required setup is performed.

• Never manually initialize any globals, classvariables etc. from within a workspace and expect these to be present when you start ST/X anew.

  (Doing so may give you a working setup while running the current image, but lead to trouble (i.e. uninitialized objects) when you ever compile your classes to machine code and start ST/X without an image.)

• Since the order of initialization is undefined (except for superclasses), do not depend on any other classes being already initialized, or any system resources (display, views, fonts, files etc.) being accessible, when your classes' #initialize method is invoked.
  If you need any of the above during initialization time, read the startup actions description below.

• If resources from other classes are required in the #initialize method,
  • either send #initialize to the other class from your classes initialize method

  • or, use a two-step initialization, by making your class a dependent of ObjectMemory and handling the #restarted or #returnFromSnapshot notification in an #update: method.

• All classes' #initialize methods should be prepared being invoked multiple times, without getting confused. This is due to the above reason; another class may invoke #initialize since it does not know whether the other class was already initialized. Typically, an initialize method checks for any of its initialized class variables being already non-nil.

• Be especially careful with private classes - since their inheritance may lead to them being initialized after the owning class, do not depend on private classes being in a usable state at the time when the owners #initialize is invoked.
  If required, use a two-step initialize.

• Although it should be already clear from the above, keep in mind:
  Do not open any views in a classes #initialize method; the view and display handling classes are usually not initialized at that time.
  If you want views to open automatically, make your class a dependent of ObjectMemory (in the #initialize method) and open the views in the classes #update: method.

• The "main()" C-function in "librun/main.c" is called.
  Since this file is provided in source , this allows adding specific actions for special applications to be added.
  Especially, any user supplied C-code can be initialized there.

• memory is initialized, command line arguments are parsed, an the symbol table management is initialized.

The followup actions depend on whether this is a clean startup (i.e. without an image) or a startup from a snapshot image.

Clean Startup

• The "stxPreInit()" C-function is called.
  This is a user supplied C-function (and defaults to an empty function). Another hook, at which special code can be executed. At the time this is called, the object memory, global and symbol tables are already initialized.

• all class, method and literal objects are created
  Every class in the system is found in this stage and registered internally. Also, the classes methodDictionaries are built here.
  Technically, this is done by calling all class libraries "Init()" function, which installs the class(es).
  (This is the phase during which the rotating wheel is shown on the terminal)

• send "Smalltalk initializeSystem" .
  This is the first time the smalltalk world is entered. This method in turn:
  • sends "Object initialize".

  • sends "ExternalStream initialize".

  • initializes the globals Stdin, Stdout and Stderr.

  • initializes the systemPath

  • sends #initialize to all other classes in the system (*).

    Notice, that at this time, the externalStreams Stdin, Stdout and Stderr are already initialized and I/O on those objects is possible (thats the reason for ExternalStream being initialized manually, before all other classes).

    However, also notice that the graphical classes have not yet been initialized - it is not possible to open any views or boxes during this phase.

  • enables some interrupts (sets handler objects)

  • sends a change notification "ObjectMemory changed:#initialized".
    Classes which need to perform any automatic actions after all other initializations are done (especially: want to allocate resources, access files etc.), should register themself as a dependent of ObjectMemory in their #initialize method, and perform these second stage initialization actions in their #update: method.

• The "stxPostInit()" C-function is called.
  This is a user supplied C-function (and defaults to an empty function). Another hook, at which special code can be executed. At this time, all classes are initialized.

• send startSelector to startClass
  Those two are set via define constants and can be changed by recompiling "main.c".
  If "main.c" file was compiled with -DDIRECT_START, the above startup message is immediately sent to start execution.
  Otherwise, #start is sent to the Smalltalk class, and startSelector and startClass are passed in classVariables. The startup-message will then be sent there, after the processScheduler has been initialized and scheduling is enabled.

  I.e. if "main.c" is compiled without -DDIRECT_START, the processor scheduler (and therefore thread-management) is already setup and running at the time of the startSelector-methods invocation, and all timer handling and interrupt processing is done as usual.
  With this compiler flag, these facilities are not setup, and the code runs bar-bones as a single thread. This may be useful for single threaded low-level code (which does not require any threading) or if you want to install your own scheduler.

  By compiling a different "main.c", you can arrange for any other method to be called instead (either immediately or after process setup).
  (BTW: this is how stand alone applications are built)

  The "Smalltalk start method in turn:

  • reads the "patches" file
    The main action done here is to read the "abbrev.stc" file, and install Autoload-stub classes for all entries found there.
    This is also a place to add patches, which are to be installed automatically.

  • reads any ".rc" file (either "smalltalk.rc" or an application specific file)
    These files perform most customizations.

  • starts an event dispatcher process for the display

  • enters the processors scheduler

  • forks a thread to perform any startup actions as defined in the startup files and (if given) to execute the startup message. (**).

  Have a look at the implementation of Smalltalk start for more details.

Notes:

(*)

The runtime system makes certain, that superclasses are initialized before any subclass. However, for classes within the same inheritance level, the order is not defined.

(**)

This is different than it used to be in previous version of ST/X, where no extra process was forked for the startup actions.
The change was made to allow startup actions to readWait on any socket, pipeStream etc., which would not be possible, if the initial process (which runs before the process scheduler is enabled) did this.

Very specialized applications, which do not need process scheduling or which want to implement their own scheduling mechanisms, may use the DIRECT_START feature, to get their own code called, without any standard (ST/X) setups being performed.
However, it is then their responsibility to correctly initialize the system.

• the image is read

• The "stxPostInit()" C-function is called.
  

• The "stxPostReInit()" C-function is called.
  This is a user supplied function (and defaults to an empty function). Another hook, at which special code can be executed. At this time, the object memory, global and symbol tables are initialized.

• send restartSelector to startClass
  These two are defined in "main.c" and default to "Smalltalk" and "restart" respectively.

The "patches" script first checks for some required classes to be present in the system, and then looks for a subdirectory called "stxPatches" and (if present) loads all files found there.

The "smalltalk.rc" script sets up various common settings, installs autoloaded classes (see below), consults the scripts "host.rc" and "display.rc", and finally invokes "private.rc".
These other scripts are responsible for host-specific setup (printer setting), display-specific setup (screen/keyboard configuration) and the start of an initial application (the Launcher).

All of those scripts are searched along a common searchPath, and the default scripts as provided with the delivery can be overwritten, by providing a corresponding file in your current directory.

Installation of Autoloaded Classes

    Smalltalk installAutoloadedClasses

Because, this might take a long time (10 or more seconds), depending on the number of directories found and the speed of you disk/network drives, this is no longer done by default (as it used to be).

Shortcut Start with an Image

On VMS, you can start an image with the DCL command: "@myApp".

Copyright © 1995 Claus Gittinger, all rights reserved