Process discovery in a large OTP system

[Ulf Wiger (AL/EAB)]

Hi Tim,

The first thing you should try is to use the 
'applications' attribute. The application controller will
hold off starting an application until all applications
listed in 'applications' have been started.

You should make sure that once an application returns
to the application controller, it is ready to serve
request. One way to do this is to use start phases:

- Have the Mod:start/2 function call supervisor:start_link()
  which starts all processes in the application
- Specify start_phases that perform any initialization that
  cannot be done elegantly in the init() functions of each
  process.

/Uffe

> -----Original Message-----
> From: owner-erlang-questions@REDACTED
> [mailto:owner-erlang-questions@REDACTED]On Behalf Of Tim Bates
> Sent: den 6 september 2005 15:28
> To: erlang-questions@REDACTED
> Subject: Process discovery in a large OTP system
> 
> 
> Hi folks,
> I'm having some difficulty with the start-up procedure of my 
> OTP-based 
> system. Specifically, some applications start up faster than 
> others and 
> so Application A reaches its configuration phase faster than 
> Application 
> B and starts making requests of processes in Application B before 
> they're initialised.
> 
> I know one way to address this is to use included applications and 
> start_phases. However I don't want to include the 
> applications in each 
> other, I'd like them to stand alone so I can shift them 
> around and things.
> 
> Someone on IRC suggested having each application's start() 
> function not 
> return until all the processes in that application are 
> initialised, but 
> I can't see an elegant way to do this.
> 
> I've also heard someone say on this mailing list that they seldom use 
> registered processes, which smacks of global state, and 
> instead manage 
> to pass around pids to only the processes that need them. 
> Again, I don't 
> know of an elegant structure that would allow me to do this 
> for all the 
> disparate parts of my system.
> 
> Can someone offer some guidance in this matter?
> 
> Thanks,
> Tim.
> 
> -- 
> Tim Bates
> tim@REDACTED
>