Each registry (i.e. the self.pool variable on any model instance) is kept in sync across workers through the database. Two sequences in database are used, one for the caches and one for the registry itself (e.g. to keep track of the fact a module has been installed), and each worker checks those sequences.

Whenever the sequences have a different value than what the worker was assuming, the workers will either clean their caches or reload the registry (thus loading any newly installed module, as it would have been flagged as "installed" in ir.module.module).

The check on the sequences is done right when a new RPC call is done. Sequences are updated at the end of an RPC call. So there is some latency between a cache invalidation on a worker and the corresponding invalidation on another worker. But this is in fact ok: when the signaling occurs, it is itself part of the database transaction associated to the RPC call. Since the check is done right at the beginning of a new RPC call, that call/transaction will see correctly cleaned caches and updated registry.

See Guewen Baconnier's answer for the few places where the logic is implemented.

To have all that signaling occur, the openerp.multi_process symbol must be set to True. This should be set in the configuration file used with Gunicorn or other WSGI servers.

In trunk, the oe web command sets also openerp.multi_process to True so that multiple oe web processes can be run side by side.