forwardcom forum

I want to add a feature for event handlers. It will work like this:
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.

What do you think? My idea is to have a standardized event system to replace the many platform-specific, framework-specific, compiler-specific, and application-specific event systems currently in use, and to provide a standardized way of handling errors, user commands, system events, etc.

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.

Interesting.

I'd add one information to the handers : a void* pointer that can be used by the event handler to store a pointer to the data structure it needs to do it's job. (typically a dynamicly allocated object, where pointers to any data that needs to be accessed.) This removes the need to handle global variables in events.

There will probably be a need to have a switch to enable each event to make sure it doesn't trigger when nothing else is initialized and ready to handle it. It could also be useful to temporarily disable the events to prevent race conditions.

Another thing you will need to specify is which thread will call the events. This is important to know where to place the mutex locks. Timer events are particularly sensitive to this: sometimes you need a very tight timer, and you don't want it to be called from something like the GUI thread. Or maybe your timer is for doing GUI animation, and then you do want the timer callback to happen on the GUI thread!

One suggestion for an extra event type : an event for apps that are streaming sound, to fill a sound buffer.