172 CHAPTER 8. CASE STUDIES
apply, cancel_timer, check_process_code,
delete_module, demonitor, disconnect_node, erase,
group_leader, halt, link, load_module, monitor_node,
open_port, port_close, port_command, port_control,
process_flag, processes, purge_module, put, register,
registered, resume_process, send_nosuspend, spawn,
spawn_link, spawn_opt, suspend_process, system_flag,
trace, trace_info, trace_pattern, unlink, unregister,
yield.
The reason for this classification is that any code fragment which calls
one of these BIFs is potentially dangerous.
Notice that I have chosen a particularly simple definition of “dirty.” At
first sight it might appear that it would be bett er to recur sively define a
module as being dirty if any function in the module calls a “dangerous”
BIF or a dirty function in another module. Unfortunately with such a
definition virtually every module in the system would be classified as dirty.
The reason for this is that if you compute the transitive closure of all
functions calls exported from a particular module, the transitive closure
will include virtually every module in the system. The reason why the
transitive closure is so large is due to “leakage” which occurs from many
of the modules in the Erlang libraries.
We take the simplifying view that all modules are well-written and
tested, and that if they do contain side-ecects, that the module has been
written in such a way so that the side ecects do not leak out from the
module to adversely acect code which calls the module.
With this definition 65% of all modules are clean. Since any module is
considered dirty if it contains a single dirty function, it is more interesting
to look at the ratio of clean/dirty functions. A function will be considered
dirty if a single call is made to unclean BIF. Viewed at a function level 92%
of all functions appear to be written in a side-ecect free manner.
Note that there were a total of 4090 dirty functions contained in 1.13
million lines of code, this is less than four dirty functions per thousand
lines of code.
The distribution of dirty functions is shown in Figure 8.1. The distri-