overview.edoc 3.2 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485
  1. @author Ulf Wiger <ulf.wiger@erlang-solutions.com>
  2. @author Joseph Wayne Norton <norton@geminimobile.com>
  3. @doc Extended process dictionary
  4. <h2>Note</h2>
  5. Gproc has two dependencies: `gen_leader' and `edown'. Since most people don't
  6. actively use either, they are no longer fetched by default.
  7. <ul>
  8. <li>To enable fetching of `gen_leader', export the OS environment variable
  9. `GPROC_DIST=true' (this can be done e.g. from a GNU Makefile)</li>
  10. <li>`edown' is fetched on-demand whenver `rebar get-deps doc' is called (which
  11. happens when you call `make doc')</li>
  12. </ul>
  13. <h2>Introduction</h2>
  14. Gproc is a process dictionary for Erlang, which provides a number of useful features beyond what the built-in dictionary has:
  15. <ul>
  16. <li>Use any term as a process alias</li>
  17. <li>Register a process under several aliases</li>
  18. <li>Non-unique properties can be registered simultaneously by many processes</li>
  19. <li>QLC and match specification interface for efficient queries on the
  20. dictionary</li>
  21. <li>Await registration, let's you wait until a process registers itself</li>
  22. <li>Atomically give away registered names and properties to another process</li>
  23. <li>Counters, and aggregated counters, which automatically maintain the
  24. total of all counters with a given name</li>
  25. <li>Global registry, with all the above functions applied to a network of nodes</li>
  26. </ul>
  27. <h3>Use case: System inspection</h3>
  28. Gproc was designed to work as a central index for "process metadata", i.e.
  29. properties that describe the role and characteristics of each process. Having
  30. a single registry that is flexible enough to hold important types of property
  31. makes it easier to (a) find processes of a certain type, and (b) query and
  32. browse key data in a running system.
  33. <h3>Use case: Pub/Sub patterns</h3>
  34. An interesting application of gproc is building publish/subscribe patterns.
  35. Example:
  36. <pre lang="erlang">
  37. subscribe(EventType) ->
  38. %% Gproc notation: {p, l, Name} means {(p)roperty, (l)ocal, Name}
  39. gproc:reg({p, l, {?MODULE, EventType}}).
  40. notify(EventType, Msg) ->
  41. Key = {?MODULE, EventType},
  42. gproc:send({p, l, Key}, {self(), Key, Msg}).
  43. </pre>
  44. <h3>Use case: Environment handling</h3>
  45. Gproc provides a set of functions to read environment variables, possibly from
  46. alternative sources, and cache them for efficient lookup. Caching also provides
  47. a way to see which processes rely on certain configuration values, as well as
  48. which values they actually ended up using.
  49. See {@link gproc:get_env/4}, {@link gproc:get_set_env/4} and
  50. {@link gproc:set_env/5} for details.
  51. <h2>Testing</h2>
  52. Gproc has a QuickCheck test suite, covering a fairly large part of the local
  53. gproc functionality, although none of the global registry. It requires a
  54. commercial EQC license, but rebar is smart enough to detect whether EQC is
  55. available, and if it isn't, the code in gproc_eqc.erl will be "defined away".
  56. There is also an eunit suite, covering the basic operations for local and
  57. global gproc.
  58. <h2>Building Edoc</h2>
  59. By default, `./rebar doc` generates Github-flavored Markdown files.
  60. If you want to change this, remove the `edoc_opts' line from `rebar.config'.
  61. Gproc was first introduced at the ACM SIGPLAN Erlang Workshop in
  62. Freiburg 2007 (<a href="erlang07-wiger.pdf">Paper available here</a>).
  63. @end