Circular dependencies during compilation

This is a bit of a theoretical question – I was cleaning up some logic in my Phoenix router.ex and I noticed that I can’t reference public functions that are defined in the router because the module isn’t yet available. When I think about it, I guess that makes sense: the plug and other macros have to run in order for the module to compile, so any functions that the module has are not yet available when the macros are running. So I put some of my helper functions into a separate file.

But that got me thinking… is it possible to have circular dependencies when compiling? E.g. module A has macros that call functions in module B, but module B has macros that call functions in module A? = Deadlock? Is that possible?

1 Like

It is not, and the compiler will provide a handy error message if you do this by accident:

== Compilation error in file lib/a.ex ==
** (CompileError)  deadlocked waiting on module B
    lib/a.ex:2: (module)
    (stdlib 3.11.2) erl_eval.erl:680: :erl_eval.do_apply/6

== Compilation error in file lib/b.ex ==
** (CompileError)  deadlocked waiting on module A
    lib/b.ex:2: (module)
    (stdlib 3.11.2) erl_eval.erl:680: :erl_eval.do_apply/6

Compilation failed because of a deadlock between files.
The following files depended on the following modules:

  lib/a.ex => B
  lib/b.ex => A

Ensure there are no compile-time dependencies between those files and that the modules they reference exist and are correctly named

Where:

# a.ex
defmodule A do
  B.foo()
end

# b.ex
defmodule B do
  A.foo()
end

5 Likes