An I/O server is any process capable of handling the I/O protocol. There is no generic I/O server behavior, but could well be. The framework is simple, a process handling incoming requests, usually both I/O-requests and other I/O device-specific requests (positioning, closing, and so on).

The example I/O server stores characters in an ETS table, making up a fairly crude RAM file.

The module begins with the usual directives, a function to start the I/O server and a main loop handling the requests:

The main loop receives messages from the client (which can use the the io module to send requests). For each request, the function request/2 is called and a reply is eventually sent using function reply/3.

The "private" message {From, rewind} results in the current position in the pseudo-file to be reset to 0 (the beginning of the "file"). This is a typical example of I/O device-specific messages not being part of the I/O protocol. It is usually a bad idea to embed such private messages in io_request tuples, as that can confuse the reader.

First, we examine the reply function:

It sends the io_reply tuple back to the client, providing element ReplyAs received in the request along with the result of the request, as described earlier.

We need to handle some requests. First the requests for writing characters:

The Encoding says how the characters in the request are represented. We want to store the characters as lists in the ETS table, so we convert them to lists using function unicode:characters_to_list/2. The conversion function conveniently accepts the encoding types unicode and latin1, so we can use Encoding directly.

When Module, Function, and Arguments are provided, we apply it and do the same with the result as if the data was provided directly.

We handle the requests for retrieving data:

Here we have cheated a little by more or less only implementing get_until and using internal helpers to implement get_chars and get_line. In production code, this can be inefficient, but that depends on the frequency of the different requests. Before we start implementing functions put_chars/2 and get_until/5, we examine the few remaining requests:

Request get_geometry has no meaning for this I/O server, so the reply is {error, enotsup}. The only option we handle is binary/list, which is done in separate functions.

The multi-request tag (requests) is handled in a separate loop function applying the requests in the list one after another, returning the last result.

We need to handle backward compatibility and the file module (which uses the old requests until backward compatibility with pre-R13 nodes is no longer needed). Notice that the I/O server does not work with a simple file:write/2 if these are not added:

{error, request} must be returned if the request is not recognized:

Next we handle the different requests, first the fairly generic multi-request type:

We loop through the requests one at the time, stopping when we either encounter an error or the list is exhausted. The last return value is sent back to the client (it is first returned to the main loop and then sent back by function io_reply).

Requests getopts and setopts are also simple to handle. We only change or read the state record:

As a convention, all I/O servers handle both {setopts, [binary]}, {setopts, [list]}, and {setopts,[{binary, boolean()}]}, hence the trick with proplists:substitute_negations/2 and proplists:unfold/1. If invalid options are sent to us, we send {error, enotsup} back to the client.

Request getopts is to return a list of {Option, Value} tuples. This has the twofold function of providing both the current values and the available options of this I/O server. We have only one option, and hence return that.

So far this I/O server is fairly generic (except for request rewind handled in the main loop and the creation of an ETS table). Most I/O servers contain code similar to this one.

To make the example runnable, we start implementing the reading and writing of the data to/from the ETS table. First function put_chars/3:

We already have the data as (Unicode) lists and therefore only split the list in runs of a predefined size and put each run in the table at the current position (and forward). Functions split_data/3 and apply_update/2 are implemented below.

Now we want to read data from the table. Function get_until/5 reads data and applies the function until it says that it is done. The result is sent back to the client:

Here we also handle the mode (binary or list) that can be set by request setopts. By default, all OTP I/O servers send data back to the client as lists, but switching mode to binary can increase efficiency if the I/O server handles it in an appropriate way. The implementation of get_until is difficult to get efficient, as the supplied function is defined to take lists as arguments, but get_chars and get_line can be optimized for binary mode. However, this example does not optimize anything.

It is important though that the returned data is of the correct type depending on the options set. We therefore convert the lists to binaries in the correct encoding if possible before returning. The function supplied in the get_until request tuple can, as its final result return anything, so only functions returning lists can get them converted to binaries. If the request contains encoding tag unicode, the lists can contain all Unicode code points and the binaries are to be in UTF-8. If the encoding tag is latin1, the client is only to get characters in the range 0..255. Function check/2 takes care of not returning arbitrary Unicode code points in lists if the encoding was specified as latin1. If the function does not return a list, the check cannot be performed and the result is that of the supplied function untouched.

To manipulate the table we implement the following utility functions:

The function check provides an error tuple if Unicode code points > 255 are to be returned if the client requested latin1.

The two functions until_newline/3 and until_enough/3 are helpers used together with function get_until/5 to implement get_chars and get_line (inefficiently):

As can be seen, the functions above are just the type of functions that are to be provided in get_until requests.

To complete the I/O server, we only need to read and write the table in an appropriate way:

The table is read or written in chunks of ?CHARS_PER_REC, overwriting when necessary. The implementation is clearly not efficient, it is just working.

This concludes the example. It is fully runnable and you can read or write to the I/O server by using, for example, the io module or even the file module. It is as simple as that to implement a fully fledged I/O server in Erlang.