Progress on callbacks

The next release will include callbacks for extension modules. As mentioned before, these have been requested for a long time, and I must admit that handling callbacks was more difficult than I had anticipated.

There are two types of callbacks: synchronous and asynchronous. The first is like a normal function call, but goes from C code into REBOL code. The second is more like an event, which will queue the callback for handling later.

The main issue was how to handle these event-driven callbacks. They occur if your extension module has passed its own C-based callback to the operating system, and as a result you want a REBOL function to run... once REBOL resumes processing.

Such events must be processed using the normal event system. So, a new callback event type has been added. The C code creates a structure that holds the function's context (the object where it is defined), the function's name, its arguments (are RXIARGs) and space for its return value. This information is queued, along with the event, and once REBOL resumes evaluation, the callback will occur.

However, it's not entirely that simple. All events must be related to ports. For example, GUI events go to the event port and trigger its awake function. Therefore, a callback event must go to a callback port.

Fortunately, a generic C-based port handler (same one that handles GUI events) can be used, so very little extra code is needed. The awake handler in the callback port calls a special function, do-callback that knows how to process the event and its special callback structure. I choose this method over that of making the system port do some kind of magical callback for callback events. Now they're like all other events. No magic.

2 Comments