7.9 I/O tabling

In Mercury, predicates that want to do I/O must take a di/uo pair of I/O state arguments. Some of these predicates call other predicates to do I/O for them, but some are I/O primitives, i.e. they perform the I/O themselves. The Mercury standard library provides a large set of these primitives, and programmers can write their own through the foreign language interface. An I/O action is the execution of one call to an I/O primitive.

In debugging grades, the Mercury implementation has the ability to automatically record, for every I/O action, the identity of the I/O primitive involved in the action and the values of all its arguments. The size of the table storing this information is proportional to the number of tabled I/O actions, which are the I/O actions whose details are entered into the table. Therefore the tabling of I/O actions is never turned on automatically; instead, users must ask for I/O tabling to start with the ‘table_io start’ command in mdb.

The purpose of I/O tabling is to enable transparent retries across I/O actions. (The mdb ‘retry’ command restores the computation to a state it had earlier, allowing the programmer to explore code that the program has already executed; see its documentation in the Debugger commands section below.) In the absence of I/O tabling, retries across I/O actions can have bad consequences. Retry of a goal that reads some input requires that input to be provided twice; retry of a goal that writes some output generates duplicate output. Retry of a goal that opens a file leads to a file descriptor leak; retry of a goal that closes a file can lead to errors (duplicate closes, reads from and writes to closed files).

I/O tabling avoids these problems by making I/O primitives idempotent. This means that they will generate their desired effect when they are first executed, but reexecuting them after a retry won’t have any further effect. The Mercury implementation achieves this by looking up the action (which is identified by a I/O action number) in the table and returning the output arguments stored in the table for the given action without executing the code of the primitive.

Starting I/O tabling when the program starts execution and leaving it enabled for the entire program run will work well for program runs that don’t do lots of I/O. For program runs that do lots of I/O, the table can fill up all available memory. In such cases, the programmer may enable I/O tabling with ‘table_io start’ just before the program enters the part they wish to debug and in which they wish to be able to perform transparent retries across I/O actions, and turn it off with ‘table_io stop’ after execution leaves that part.

The commands ‘table_io start’ and ‘table_io stop’ can each be given only once during an mdb session. They divide the execution of the program into three phases: before ‘table_io start’, between ‘table_io start’ and ‘table_io stop’, and after ‘table_io stop’. Retries across I/O will be transparent only in the middle phase.