As occam is a much safer language than C, as much of the logic as possible should be handled in occam. However, there are some things that are handled in C which could have been handled in occam. It would have been possible to just have occam use blocking C calls to the MySQL C API, and thus avoid having a CIF process running C code altogether. However, that would make it necessary to store the necessary C data structures as byte arrays in occam, which is not very nice.
Instead, we have a C process where the necessary data structures are stored. The communication between the occam and C process is quite low level since channels to C processes are limited in type. Five channels are used to communicate between occam and C. control, argi and args goes from occam to C and status and data goes from C to occam. control, argi and status carry type INT while args and data carry type MOBILE []BYTE.
control is used to send commands to the C process to signal which function in the C API should be called. Subsequently, integer arguments are sent on argi and string arguments on args, the number and type of arguments being dependent on the command.
If the command can fail, a value is sent back via. the status channel indicating success or failure. If any values are returned they are sent back sequentially via. the status and data channels depending on the type.
All error handling is done in occam, so the only functionality residing in the C process is converting the various C strings and other data types to MOBILE []BYTEs and values that occam understands.
It should be okay to have several MySQL processes running in parallel if the MySQL C client library is compiled thread-safe. However, the initialisation call to the API is not thread-safe. For this reason, it is provided in MoA as a process that should terminate before starting any MySQL processes in parallel. This is the only way to provide this functionality, as there is no way for the MySQL processes to atomically check if they are the first MySQL process to run.
Some of the commands to the MySQL process are very similar, so to avoid code duplication we want the same piece of code to handle these. For this reason, a wrapper process translates the commands for the application programmer before they are passed to the main process of the API for processing. To be really neat, we should translate from the API protocol to an internal protocol, but the translation is so simple that we just re-use the API protocol.
It would have been nice to provide the various field names as part of the MYSQL.FIELD.INFO record instead of selecting with a control byte (see section 8.7.9), but the current version of KRoC (1.4.0) doesn't seem to support mobile arrays of mobile records.