A source code file can define any number of event handlers. Each event handler has a record with the following information: event id, priority, key, and a relative pointer to a function to handle the event. The linker makes a list of all the event handlers and sorts the list by id, key, and priority. The sorted list is put into the executable file. A piece of software will search the list of event handlers when an event occurs and call the corresponding event handler function. If there are more than one handler for the event then they will be called in the order of priority.
This event handler system will serve several different purposes:
- construction event. This is called when the program is started, before calling main(). This may be used for initializing function libraries, calling static constructors, and any other initialization. This replaces the constructors section of current systems.
- destruction event. This is called when the program is finished, after main() has returned. This replaces the destructors section of current systems.
- load library event. Called when a library has been dynamically loaded. Performs any necessary initialization of the library.
- unload library event. Called when a dynamically loaded library is about to be unloaded. Performs any necessary cleanup.
- close process event. A request for closing the current application.
- error event. This should be a standardized system for handling error messages. This is useful for example if a library function needs to report an error. The method for reporting errors depends on the platform and user interface framework. Console mode programs should write error messages to stderr. GUI programs should pop up a messagebox. And server programs should write to an error log and send a message to the administrator. All these details are unknown to the library function, but we can insert different event handlers for different platforms to handle error events in an appropriate manner. We need a standardized system for reporting errors, and the absense of such a standard in contemporary computer systems is a big problem.
- timer event.
- command event. This will handle commands from the user of a running GUI application. The value of the event key indicates the id of a hotkey, a menu item, or an icon that has been clicked. The application program has event handlers for each user command. Add-on modules may have handlers for additional user commands.
- message events. This can be useful for message-based programs and inter-process communication.
- call events. This can be used for calling functions in an add-on module if there is no direct link to the function name.
I am working on the linker right now. This event handler system is quite simple to implement. The sorted event list provides an efficient way of searching for the handler for a particular event.