[erlang-questions] initializing library applications without processes

[karol skocik]

No worries, my lib/app already worked that way 5 minutes after your
suggestion :)
Thanks, Karol

On Sat, Apr 3, 2010 at 10:16 PM, Ulf Wiger
<ulf.wiger@REDACTED> wrote:
>
> Just beware that my example is mailing-list-quality code.
> I've not tried to compile or run it. It is only "obviously
> correct".
>
> BR,
> Ulf W
>
> karol skocik wrote:
>>
>> "Hijacking" supervisor this way is pretty nice idea :)
>> Will do for my case.
>>
>> Thank you guys for suggestions.
>> Karol
>>
>> On Sat, Apr 3, 2010 at 8:41 PM, Ulf Wiger
>> <ulf.wiger@REDACTED> wrote:
>>>
>>> I received exactly this question while at the SF Erlang Factory.
>>>
>>> My suggestion is: start a supervisor with no children. A reasonable
>>> "cheat" is to put all of this in the app file
>>>
>>> -module(myapp).
>>> -behaviour(application).
>>> -export([start/2, stop/1]).
>>> -behaviour(supervisor).
>>> -export([init/1]).
>>>
>>> start(_, _) ->
>>>  supervisor:start_link({local,?MODULE},?MODULE,[]).
>>>
>>> stop(_) -> ok.
>>>
>>> init([]) ->
>>>  %% create tables here...
>>>  {ok, {{one_for_one,3,10},[]}}.
>>>
>>> Baking the supervisor into the application callback module is
>>> in a sense against the OTP design rules, but the most notable
>>> example of this is surely OTP's 'kernel' application, so you
>>> won't be tarred and feathered for doing so. :)
>>>
>>> BR,
>>> Ulf W
>>>
>>> karol skocik wrote:
>>>>
>>>> Hi,
>>>>  sometimes, I just need a library "application" without processes,
>>>> which works with some state in ETS. To function properly,
>>>> they have to make the ETS table and populate it with values
>>>> from config files. When that step is done, there is nothing left to do
>>>> for processes, they would just serve as a useless proxy for
>>>> querying the ETS table, and that's not needed when you can (in some
>>>> contexts)
>>>> access the table directly.
>>>>
>>>> I like the mechanism of applications and their dependency solving,
>>>> and I would ideally do application:start(my_app_with_ets_initialised)
>>>> but that won't do, since {ok, SupPid} is expected as a result.
>>>>
>>>> But I don't want to start any processes, I just want to ensure that
>>>> application_master:init/4 calls my "start" function,
>>>> and declare application as "running" when 'ok' is returned
>>>> or fail otherwise (unless it's {ok, SupPid} - as it is now).
>>>>
>>>> Currently, when we have library application, application:start(...)
>>>> does not call anything since 'mod' is not specified in .app file.
>>>> Could it be changed, and application behaviour would just call
>>>> start/2 and stop/1 as usual, but start the SupPid optionally when it's
>>>> supplied?
>>>> Or - alternatively - is there any way how to ensure that some init
>>>> function is done
>>>> fitting nicely with application dependencies as declared in .rel file?
>>>>
>>>> Thanks,
>>>>  Karol
>>>>
>>>> ________________________________________________________________
>>>> erlang-questions (at) erlang.org mailing list.
>>>> See http://www.erlang.org/faq.html
>>>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>>>>
>>>
>>> --
>>> Ulf Wiger
>>> CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd
>>> http://www.erlang-solutions.com
>>> ---------------------------------------------------
>>>
>>> ---------------------------------------------------
>>>
>>> WE'VE CHANGED NAMES!
>>>
>>> Since January 1st 2010 Erlang Training and Consulting Ltd. has become
>>> ERLANG
>>> SOLUTIONS LTD.
>>>
>>> www.erlang-solutions.com
>>>
>>>
>>
>> ________________________________________________________________
>> erlang-questions (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>>
>
>
> --
> Ulf Wiger
> CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd
> http://www.erlang-solutions.com
> ---------------------------------------------------
>
> ---------------------------------------------------
>
> WE'VE CHANGED NAMES!
>
> Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG
> SOLUTIONS LTD.
>
> www.erlang-solutions.com
>
>