[erlang-questions] non-trivial supervisor idioms?

[Edmond Begumisa]

Hi again Ulf,

It's great to get 'the guy' on this subject online so I'm going to take  
full advantage and ask two more questions that have been dogging me...

Firstly, is there an open-source project you know of that uses  
included-applications and/or start phases properly that I could take a  
peek at? Maybe in OTP source itself?

Secondly, I've always liked the idea of using included applications not  
necessarily for start phases but as a delayed/start-on-demand mechanism  
(taking advantage of the fact that included apps are automatically loaded  
but not started.) That is, manually calling application:start(foo) only if  
a particular feature of my app is used. But I have one query that made  
attempts for such use short-lived... the fact that an application can only  
be included by one other application. I think this limitation makes it  
harder to use included apps and start phases especially if you're using  
apps that are not in-house.

For example, lets say CouchDB starts using mnesia (ok that's dumb but...)  
and decide to start it up using start phases (and therefore add it as an  
included application in couch.app) Then I have my FunkyApp that's been  
using mnesia too as included application. I then decide to use CouchDB for  
a new funky feature of FunkyApp. Now things break because mnesia is being  
used by both FunkyApp and CouchDB. To fix this, I not only have to modify  
my in-house app I have to modify the out-house CouchDB too.

Is there an obvious fix to this I've been missing?

- Edmond -

On Tue, 28 Sep 2010 03:19:29 +1000, Ulf Wiger  
<ulf.wiger@REDACTED> wrote:


On 27 Sep 2010, at 18:14, Edmond Begumisa wrote:

Ulf,

I've been doing such initialisation in the init function of a worker  
manager process. Using Daniel's example, I might have a gen_server child  
of the main supervisor called db_mgr and set up the mnesia schema in  
db_mgr:init

Have I been doing the 'wrong' thing OTP-wise?

Not necessarily, but my personal preference is to cleanly separate setup  
code
 from application startup. This is in part because I used to work on a very  
complex
product, where the setup was decidedly non-trivial, and the startup  
process had
to be optimised in several steps.

Still, even there, I believe that the setup logic was bootstrapped into  
the startup
phase, but the code was still kept cleanly separated. The only thing that  
was
part of the startup was a simple check to see if the setup code had been  
run.

BR,
Ulf W



- Edmond  -

On Tue, 28 Sep 2010 00:31:47 +1000, Ulf Wiger  
<ulf.wiger@REDACTED> wrote:

On 27/09/2010 16:15, Daniel Goertzen wrote:
I've read the documentation on supervision and have seen a few tutorials,
but they don't seem to move beyond the core concepts.  For example, what
happens if you want to check and optionally setup an mnesia schema during
startup...where should this code go?  In the supervisor init() or
start_link() function?  Should I have my supervisor create a worker process
whole sole job is to do this kind of setup and then dynamically add other
workers (or supervisors) to the supervisor with start_child()?

I strongly recommend doing that sort of thing in a separate procedure,
rather than in the startup phase.

If you want your application to be able to bootstrap itself, I would
suggest that you either:

- create a special application that runs before your other apps,
   and verifies that the installation is ok. To this end, it might be
   useful to know that you can pre-sort the .rel file. The systools lib
   will only change the sort order if needed to respect start
   dependencies.
- Introduce start_phases, then do minimal work in the init function,
   and push the rest to functions that are called from start phase
   hooks. This also has the advantage that you know that your processes
   are all started and ready to respond during the init phase.

Start phases are documented in
http://www.erlang.org/doc/apps/kernel/application.html#Module:start_phase-3

BR,
Ulf W



--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Ulf Wiger, CTO, Erlang Solutions, Ltd.
http://erlang-solutions.com




________________________________________________________________
erlang-questions (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED



--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/