Asynchronous I/O
1. Bare Metal
The best way to do asynchronous I/O with FBP, is to throw away the O/S and run off of hardware interrupts. When a hardware input fires, it wakes up the kernel and lets it run until the all of the components that handle the input have run to completion.
This requires the use of a (lockable) queue. Let’s say that two keypresses come in rapid succession, each triggering a hardware interrupt.
The first keypress interrupt wakes the kernel and hands control, i.e. the cpu, to the kernel. The kernel grabs the keypress and re-enables interrupts. Then the kernel creates an IP (a small data structure) for the keypress and runs the FBP system.
If the second keypress interrupt occurs before the kernel has returned to an idle state, then that keypress must simply be placed on the I/O queue and the 2nd interrupt ends (re-enable interrupts then RTI (return from interrupt)).
2. Inside an O/S (green thread)
2.1 Event Loop / Windows Loop
The O/S wraps the main-loop of an app inside an (expensive) process. Your code – the FBP kernel plus components simply run inside the main-loop. In this model, the O/S already queues up events (e.g. mouse events, etc.) and metes them out one at a time, calling the main-loop for each event.
Time-slicing and other expensive behaviours are supplied by the O/S as a “courtesy”.
The question arises – why bother with an FBP kernel in this case, why not just use a deep stack of calls, as was originally intended by the O/S developers?
Answer: FBP is a paradigm for designing and testing Software Architectures. Designing an app as a set of (apparently) asynchronous FBP components makes everything easier. Additionally, it makes it possible to draw sensible diagrams of the app’s architecture and to compile those diagrams to code.
Another way to think about FBP is that an FBP component is a DLL with all of its input API and output API linked at load time. A component must call other components via the link-loader’s table. This analogy can give a sense of the degree of decoupling (architecturally good) that FBP provides. The analogy is still flawed, because FBP removes the target’s name from the tables – the component cannot know which components (if any) are connected to its output tables.
2.2 Asynchronous Callbacks
This is what node.js does. You call node.js and ask it to perform some I/O. You give it a pointer to the callback routine which will be fired when the I/O has done its thing.
Everybody knows that programming with callbacks is rife with danger – all sorts of hidden interactions come into play.
FBP makes this paradigm plausible to use safely. The job of any callback is to create an IP and to call the FBP kernel.
Again, it makes total sense to build the app using call-returnless FBP, since the FBP paradigm fits perfectly into the asynchronous paradigm.
2.3 Multiple Processes / Threads / Cores / Distributed Processing
This will be discussed in a future article. Note that Paul Morrison’s book http://www.jpaulmorrison.com/fbp/book.html is a good resource to read if you can’t wait for me to write about it.
I’m probably going to head in the direction of what does a small FBP-like kernel look like, without all of the bells and whistles of current hardware and OS’es, for the next while.
bittarvydas 