There are two options that can be used to limit the cpu resources devoted to processing a given source file:

• -steps n: This allows each rule to take at most n steps. It is probably not very easy for the user to figure out what a step is, because the matching process of Coccinelle includes a fixpoint iteration (ie, loops), so the number of steps does not eg, depend on the size of the SmPL code. But 10000 might be a reasonable number. The weakness of this approach is that then the rule (eg foo) will fail if it times out, and some other rule that contains depends on !foo will be triggered. But if you don't use depends on in a way that relies on the failure of another rule then this could be a useful option.

• -timeout n: This will cause the treatment of a file to time out after n seconds. 90 or 120 might be a reasonable value for n. If you let it go too far, it will get caught up in garbage collecting and ignore the timeout message, so you want a value that is long enough to get most answers, but not long enough to let the treatment of any file get out of control.

Another option is to split your C files among multiple calls to spatch. Then if one file gets stuck it will only block the processing of the files treated by its instance of spatch.

The directory tools/distributed contains a program called spatch_linux that distributes your files among some number of processes. If you have a multicore machine, these will normally run in parallel, but it might be useful in general to mitigate the problem of spatch getting stuck on one file. spatch_linux is C code, and could probably be implemented in a better way than it currently is. Since it is mostly intended for internal use, little effort has been put into robustness or user-friendliness.